Re: Efficient bytecode generation? (Anton Ertl)
5 Apr 2003 15:14:44 -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: (Anton Ertl)
Newsgroups: comp.compilers
Date: 5 Apr 2003 15:14:44 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 03-03-096 03-03-169 03-03-192
Keywords: interpreter
Posted-Date: 05 Apr 2003 15:14:44 EST

"John R. Strohm" <> writes:
[John Levine:]
>>[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.

More like an indirect jump. However, the misprediction penalties for
the indirect branches alone can take 60% of the time. Fortunately,
there are ways to eliminate most of that, as discussed in my PLDI 2003
paper (draft at

>[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]

If you use threaded code, there is no register save and restore
overhead, since you don't use calls. You can implement threaded code
in GNU C, using the labels-as-values extension (for old Fortran-heads,
that's the same as assigned gotos). If you restrict yourself to ANSI
C, the best choice is probably to use the giant switch approach to
bytcode interpretation (slowdown over threaded code: up to a factor of
2); then you also don't have to save and restore registers.

- anton
M. Anton Ertl

Post a followup to this message

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