|[3 earlier articles]|
|Re: Need Information on how to create bytecode firstname.lastname@example.org (2006-04-09)|
|Re: Need Information on how to create bytecode Satyam@satyam.com.ar (Satyam) (2006-04-12)|
|Re: Need Information on how to create bytecode email@example.com (2006-04-12)|
|Re: Need Information on how to create bytecode firstname.lastname@example.org (DavidM) (2006-04-14)|
|Re: Need Information on how to create bytecode email@example.com (megavlad@gmail) (2006-04-17)|
|Re: Need Information on how to create bytecode firstname.lastname@example.org (kov) (2006-04-21)|
|Re: Need Information on how to create bytecode email@example.com (2006-04-25)|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Date:||25 Apr 2006 10:14:48 -0400|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|Posted-Date:||25 Apr 2006 10:14:48 EDT|
"kov" <email@example.com> writes:
>I have a question, not necessarily for you, but for the knowledgeable
>residents of comp.compilers: is p-code/bytecode the best solution?
If you want execution speed, using a virtual machine (what you
probably mean with p-code/bytecode) is certainly necessary for the
best solution. In other respects I don't see disadvantages from using
a virtual machine.
>I wrote a little scripting language once and felt sort of resigned to
>generating bytecode just as you are doing, and while it ended up
>working, debugging the scripts was a nightmare!
I don't know how you tried to debug the scripts. Trying to use gdb or
similar debuggers to single-step through interpreters is a waste of
time for any kind of interpreter, because you will see lots of
uninteresting interpreter internals, and will have a hard time seeing
the higher-level stuff you are interested in.
>In contrast, a co-worker was recently showing me a scripting language
>he'd developed which generated a parse-tree, with classes representing
>the various node-types all descended from a single basic node. The
>interpreter executed over the tree rather than P-code, and I found it
>more straightforward to step through. I also found it fairly
>flexible, allowing the development of continuations and other nifty
>stuff, and it could be stored and read from an XML file.
Having a virtual-machine representation also has the advantage that it
decouples the front end from the interpreter, whereas using a parse
tree does not. If you enhance the syntax, you usually have to enhance
a tree-interpreter, while you are often able to keep a VM interpreter
unchanged. This is especially useful if you store the compiled code
in files as you suggest, but I also found it helpful on other
>[There isn't really that much practical difference between bytecodes
>and a parse tree. A typical RPN byte code is easily generated by doing
>a depth first walk of a parse tree, and you can rebuild the tree just
>as easily as you read in the codes. -John]
That's true for expression evaluation and simple statements, but for
control flow there is a big difference between virtual-machine code
(which typcially uses virtual-machine branches) and a parse tree
(which typically represents structured control flow constructs).
M. Anton Ertl
Return to the
Search the comp.compilers archives again.