Re: What is byte-code ?

Carl Cerecke <cdc@maxnet.co.nz> writes:
>Torben Ęgidius Mogensen wrote:
>
>> bytecodes have traditionally been interpreted rather than translated,
>> it is only in the last couple of decades that bytecodes designed for
>> compilation or JIT's have emerged.
>
>What is the difference between bytecodes designed for (JIT) compilation
>and bytecodes designed for interpreting? Your comment sounds like there
>are specific design decisions regarding bytecode structure that
>facilitate compilation. Or, rather, that some design decisions can make
>compilation more difficult/inefficient.


Well, one example is static stack depth knowledge in the JVM. The
interpreter does not profit from it, but the compiler does: it can
allocate all stack items to registers or wherever it wants to. While
the stack depth is statically known in the JVM in general, there are a
few hurdles that could have been avoided if the JVM had been designed
with that in mind (IIRC subroutines are particularly nasty); I think
that the JVM was originally designed to be interpreted, and the static
features were due to it also being designed to be verifyable (for
certain safety properties).


>[I'd want my JIT code to have stronger typeing so I could figure out at
>code generation time what the datatypes of the operands all were. -John]


I assume that you mean that the types should be statically known, and
that the JIT should track types and resolve any overloading in the VM
instructions at JIT time and compile it to native code without typeq
checks.


While such a VM would be definitely interpreter-unfriendly, it's not
very JIT-friendly, either. Whatever types and overloading can be
resolved statically in your language should already be resolved by the
front-end (which typically has to deal with types anyway and perform
any static type checking), resulting in typed operations in the VM
(like JVMs iadd fadd etc.). Such a VM does not need to deal with
types (except the remaining dynamic types of the language) at either
interpreter or JIT time, making both the interpreter faster and the
JIT smaller and faster-compiling (if it is not burdened with a
verifier).


- 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.