Related articles |
---|
[3 earlier articles] |
Re: Need Information on how to create bytecode haberg@math.su.se (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 scavadini@ucse.edu.ar (2006-04-12) |
Re: Need Information on how to create bytecode amedlock@gmail.com (DavidM) (2006-04-14) |
Re: Need Information on how to create bytecode megavlad@gmail.com (megavlad@gmail) (2006-04-17) |
Re: Need Information on how to create bytecode ken.overton@gmail.com (kov) (2006-04-21) |
Re: Need Information on how to create bytecode anton@mips.complang.tuwien.ac.at (2006-04-25) |
From: | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
Newsgroups: | comp.compilers |
Date: | 25 Apr 2006 10:14:48 -0400 |
Organization: | Institut fuer Computersprachen, Technische Universitaet Wien |
References: | 06-04-048 06-04-118 |
Keywords: | interpreter |
Posted-Date: | 25 Apr 2006 10:14:48 EDT |
"kov" <ken.overton@gmail.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
occasions.
>[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).
- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html
Return to the
comp.compilers page.
Search the
comp.compilers archives again.