|Efficient bytecode generation? email@example.com (shahmil merchant) (2003-03-14)|
|Re: Efficient bytecode generation? firstname.lastname@example.org (Søren Bak) (2003-03-22)|
|Re: Efficient bytecode generation? email@example.com (2003-03-30)|
|Re: Efficient bytecode generation? firstname.lastname@example.org (John R. Strohm) (2003-03-30)|
|Re: Efficient bytecode generation? email@example.com (Eliot Miranda) (2003-04-05)|
|Re: Efficient bytecode generation? firstname.lastname@example.org (2003-04-05)|
|From:||"John R. Strohm" <email@example.com>|
|Date:||30 Mar 2003 21:28:32 -0500|
|Posted-Date:||30 Mar 2003 21:28:31 EST|
Anton Ertl" <firstname.lastname@example.org> said
> "shahmil merchant" <email@example.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
> >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
[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
Search the comp.compilers archives again.