Re: Efficient bytecode generation?

Eliot Miranda <>
5 Apr 2003 15:04:12 -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: Eliot Miranda <>
Newsgroups: comp.compilers
Date: 5 Apr 2003 15:04:12 -0500
Organization: Prodigy Internet
References: 03-03-096 03-03-169 03-03-192
Keywords: code, interpreter
Posted-Date: 05 Apr 2003 15:04:12 EST

Hi John,

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

I was one of the C compiler abusers who did this. My approach was to
use editor scripts on the C compiler's assembler output. These
scripts would essentially delete the prologue and epilog, removing any
callee-saved register saves. So one can still achieve a convention
that requires no saves and stay in C. In fact, by abstracting things
like the threaded-code jump-to-next instruction into macros one could
compile a VM using a vanilla C compiler and no editor scripts and have
it run (faster than a bytecoded interpreter) or compile to assembler
and edit into a direct threaded code machine with no overhead above
the indirect jump.

illustrations on request...
Eliot Miranda Smalltalk - Scene not herd

Post a followup to this message

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