Related articles |
---|
Efficient bytecode generation? shahmil_m@hotmail.com (shahmil merchant) (2003-03-14) |
Re: Efficient bytecode generation? anonymous-coward@get2.net (Søren Bak) (2003-03-22) |
Re: Efficient bytecode generation? anton@mips.complang.tuwien.ac.at (2003-03-30) |
Re: Efficient bytecode generation? strohm@airmail.net (John R. Strohm) (2003-03-30) |
Re: Efficient bytecode generation? eliotm@pacbell.net (Eliot Miranda) (2003-04-05) |
Re: Efficient bytecode generation? anton@mips.complang.tuwien.ac.at (2003-04-05) |
From: | Eliot Miranda <eliotm@pacbell.net> |
Newsgroups: | comp.compilers |
Date: | 5 Apr 2003 15:04:12 -0500 |
Organization: | Prodigy Internet http://www.prodigy.com |
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
Return to the
comp.compilers page.
Search the
comp.compilers archives again.