Re: Efficient bytecode generation?

Anton Ertl" <anton@mips.complang.tuwien.ac.at> said
> "shahmil merchant" <shahmil_m@hotmail.com> writes:
> Unless other criteria demand something else, go for simplicity. The
> following design is relatively easy to implement in both the front end
> (VM code generation), and in the interpreter, and is therefore used
> frequently (e.g. in the JVM): Use a stack-based approach for
> expressions, and communicate between statements with local variables.
> The examples supplied with vmgen demonstrate that approach.
>
> >[For a software interpreter, you'll probably find that a complex
high-level
> >bytecode is faster than a simple one, since the work in the interpreter
> >of cracking and dispatching the codes is significant.


Only if you are using a fancy bytecode. If you use direct- or
indirect-threaded code, it is, respectively, one or two memory fetches and a
JSR. See [Ritter & Walker] or [Loeliger] for details.


[Ritter & Walker] "Varieties of Threaded Code for Language Implementation",
by Terry Ritter and Gregory Walker (or some such), in the "Byte" magazine
special issue on FORTH, in about 1979.
[Loeliger] "Threaded Interpretive Languages", Byte Books, ca. 1979.
Complete implementation of an indirect-threaded Z-80 FORTH interpreter,
without ever actually admitting that the language being implemented was
FORTH.
[There was a lengthy thread in comp.compilers some years ago on tricking
your C compiler into doing threaded code dispatches, which worked, but
I still think the register save and restore overhead around the JSR is
a significant performance issue for simple bytecodes unless you're going
to write it all in assembler and use register conventions that let you
save nothing. -John]

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