Re: Efficient bytecode generation?

"John R. Strohm" <>
30 Mar 2003 21:28:32 -0500

          From comp.compilers

Related articles
Efficient bytecode generation? (shahmil merchant) (2003-03-14)
Re: Efficient bytecode generation? (Søren Bak) (2003-03-22)
Re: Efficient bytecode generation? (2003-03-30)
Re: Efficient bytecode generation? (John R. Strohm) (2003-03-30)
Re: Efficient bytecode generation? (Eliot Miranda) (2003-04-05)
Re: Efficient bytecode generation? (2003-04-05)
| List of all articles for this month |

From: "John R. Strohm" <>
Newsgroups: comp.compilers
Date: 30 Mar 2003 21:28:32 -0500
Organization: Compilers Central
References: 03-03-096 03-03-169
Keywords: interpreter, comment
Posted-Date: 30 Mar 2003 21:28:31 EST

Anton Ertl" <> said
> "shahmil merchant" <> 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]

Post a followup to this message

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