Re: CIL question

Stefan Mandel 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?


The IL at least is *intended* to be compiled, and contains some meta
instructions with hints for an compiler, which are quite useless for
an interpreter. AFAIK the DotGNU project uses an interpreter, with
compilation only for certain (already implemented) constructs.


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


Isn't a stack equivalent to an infinite number of registers?


And who would assign the register numbers? Correct, this would be the
task of the compiler, which translates source code into IL. But how
would such an compiler optimize the register usage, if nothing is
known about the number of available registers at runtime? On which
machine? And how many registers have to been saved and restored, when
a subroutine is called?


A stack based approach instead is self-optimizing, only the actually
used values are stored in the stack. Subroutine calls find the
arguments already on the stack, nothing must be saved, only the stack
base must be adjusted at runtime.


With a look at the preferred machine architecture of Microsoft (x86),
the number of registers is very limited, so that a register based
model would be very ineffective. With less than an infinite number of
physical registers, the JIT compiler must maintain a mapping between
the meta-registers and the machine registers, and must determine which
registers at which time to swap in or out...


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


IMO a JIT compiler can optimize register usage for the actual machine,
based on a stack organization, but from a register based model this
might be much harder to do. (It's only a feeling, I have no experience
in this area). A register based model may be fine for a compilation
into native code, but without knowledge of the number of available
registers it's only a waste of time and memory, when the precompiler
assigns register numbers, which are quite useless to the JITer.


And the code of a stack machine should be shorter than for a register
based machine, where the register numbers have to be stored in
additional bytes (or words, or even longer fields?)


My question to the gurus: Does register based code make sense, without
a chance to optimize the register usage for a known number of
registers?


DoDi
[The usual way to generate code for machines with a reasonably large
number of registers is to start by assuming an unlimited number, then
use edge coloring to assign values to actual registers and spill the
ones that don't fit. Turning stack code into register code is so
simple that I'd think that the size advantage of stack code would be
compelling for the IL. -John]

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