Re: Need Information on how to create bytecode

anton@mips.complang.tuwien.ac.at (Anton Ertl)
25 Apr 2006 10:14:48 -0400

          From comp.compilers

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)
| List of all articles for this month |

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

"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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.