Re: CIL question

On 2006-01-20, Stefan Mandel <stefan.mandel@iese.fraunhofer.de> wrote:
> I have a question to the Microsoft Intermediate language for the .NET
> framework. The specification of this language says, that it must be
> compiled and not be interpreted. Seems quite odd to me - who cares how
> this language is handled from a virtual machine?


Can you qoute the exact words you read and the page in the standard?
I don't remember anything to that effect. Instead, the standard in
several places explicitly mentions both interpretation and JIT
compilation as execution methods.


It is certainly true that CIL code can be slow to intepret as is, since,
for example, the add opcode applies to both integers and floating point
values and you need to decide which code path to take depending on the
value on the stack.


CIL code is meant to be compiled, but this doesn't mean that it must be
compiled. I, for example, implemented a CIL interpreter that we used in
the Mono project to bootstrap the C# compiler and libraries before we
implemented a JIT. I don't know of any other CIL interpreter, though
(my interpreter has been changed to jit compile to a different bytecode
that is faster to interpret, so it can't be called a CIL interpreted
anymore. The same applies to the portable.net interpreter).


> However, is there any reason that they implemented .NET-CIL as a stack
> based language? Wouldn't it have been easier to produce register code
> with an infinite number of registers?


Since CIL code is only meant to be a compact intermediate
representation, using a stack-based approach is better: the memory and
on disk space used is smaller.


> They need this (register based) representation anyway if they want to
> optimize the program. And if they explicitly disallow interpretation,
> there is no need for stack representation at all.


When the intent is to JIT the code, there is basically no difference
if you start from stack-based or from register-based bytecode. Having
register-based bytecode could even be inappropriate: how do you
represent 64 bit integers? They need different representations for 32
bit and 64 bit machines: choosing one for the on-disk format would be
the wrong choice in some setup.


A register-based bytecode representation has only one benefit: faster
interpretation. Please note that fast interpretation is not the same
as fast execution:-) If you're going to JIT the code, the
register-based info is just useless extra baggage and JIT compilation
is needed for fast execution. Fast interpretation is always going to
be about an order of magnitude slower than fast execution by a JIT.


lupus


--
-----------------------------------------------------------------
lupus@debian.org debian/rules
lupus@ximian.com Monkeys do it better

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