|Register Based Interpreter Model firstname.lastname@example.org (Avatar) (2005-11-01)|
|Re: Register Based Interpreter Model email@example.com (2005-11-02)|
|JIT-compiling bytecode firstname.lastname@example.org (Lauri Alanko) (2005-11-04)|
|Re: JIT-compiling bytecode email@example.com (Eliot Miranda) (2005-11-08)|
|From:||Lauri Alanko <firstname.lastname@example.org>|
|Date:||4 Nov 2005 14:04:05 -0500|
|Organization:||University of Helsinki|
|Posted-Date:||04 Nov 2005 14:04:05 EST|
|Originator:||email@example.com (Lauri Alanko)|
In article 05-11-025, <firstname.lastname@example.org> wrote:
> Some authors argue that a register machine is more complicated but a
> better starting point for jitting.
The idea of jitting _bytecode_ seems rather strange to me in the first
place. Bytecode is a _target_ language, after all, designed to be
efficiently interpreted by a VM with only straightforward
modifications (threading, symbol resolution), but no real syntactic
analysis. It is not a particularly good intermediate language from
which to translate to native machine code. For example, bytecode fixes
the evaluation order completely, so a jit-compiler needs to go through
hoops to reorder the computations optimally for the target platform.
To my mind, if a VM is supposed to support jitting, the code should be
stored in some higher-level format, which is then jitted at run-time
to a target language (native code or interpreted bytecode).
[Bytecode can be though of as a linearized version of a parse tree. I
don't see that it makes the situation any worse unless you want the
compiler to do a bunch of dependency analysis and dump out the
analysis results along with the code. -John]
Return to the
Search the comp.compilers archives again.