Re: Efficient bytecode generation?

"John R. Strohm" <strohm@airmail.net> 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
<http://www.complang.tuwien.ac.at/anton/tmp/interpreter-btb.ps.gz>).


>[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
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html

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