Re: What is byte-code ? (Anton Ertl)
31 Mar 2005 23:30:26 -0500

          From comp.compilers

Related articles
[8 earlier articles]
Re: What is byte-code ? (2005-03-08)
Re: What is byte-code ? (Carl Cerecke) (2005-03-08)
Re: What is byte-code ? (2005-03-15)
Re: What is byte-code ? (Chris Dollin) (2005-03-15)
Re: What is byte-code ? (Xous - Jose R. Negreira) (2005-03-18)
Re: What is byte-code ? (Nathan Moore) (2005-03-24)
Re: What is byte-code ? (2005-03-31)
Re: What is byte-code ? (2005-03-31)
Re: What is byte-code ? (Chris Dollin) (2005-03-31)
Re: What is byte-code ? (Nathan Moore) (2005-04-02)
Re: What is byte-code ? (John Slimick) (2005-04-11)
Re: What is byte-code ? (Chris Dollin) (2005-04-11)
Re: What is byte-code ? (2005-04-11)
[4 later articles]
| List of all articles for this month |

From: (Anton Ertl)
Newsgroups: comp.compilers
Date: 31 Mar 2005 23:30:26 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 05-03-015 05-03-037 05-03-043 05-03-047
Keywords: interpreter
Posted-Date: 31 Mar 2005 23:30:26 EST

Carl Cerecke <> 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

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

- anton
M. Anton Ertl

Post a followup to this message

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