Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Register Based Interpreter Model acampbellb@hotmail.com (Avatar) (2005-11-01) |
| Re: Register Based Interpreter Model christian.mueller@aktivanet.de (2005-11-02) |
| JIT-compiling bytecode la@iki.fi (Lauri Alanko) (2005-11-04) |
| Re: JIT-compiling bytecode eliotm@pacbell.net (Eliot Miranda) (2005-11-08) |
| From: | Lauri Alanko <la@iki.fi> |
| Newsgroups: | comp.compilers |
| Date: | 4 Nov 2005 14:04:05 -0500 |
| Organization: | University of Helsinki |
| References: | 05-11-016 05-11-025 |
| Keywords: | code |
| Posted-Date: | 04 Nov 2005 14:04:05 EST |
| Originator: | lealanko@cc.helsinki.fi (Lauri Alanko) |
In article 05-11-025, <christian.mueller@aktivanet.de> 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).
Lauri
[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
comp.compilers page.
Search the
comp.compilers archives again.