Re: CIL question

> Hans-Peter Diettrich wrote:
> > 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.
>
> Sorry, this seems to be nonsense, or at least we speak from different
> things. The GNU-C compiler used in Linux is based on representation with
> an infinite number of registers, the compiler of microsoft and intel
> probably too. And also research compiler frameworks (like FIRM or SUIF)
> work with SSA-Form which has an infinite number of registers.
>
> The key is, that the infinite number of registers is mapped to the
> available registers of the underlying machine (which is quite different
> on Intel architectures or RISC processors). I yet do not know how to map
> stack code (might work too) and I am convinced that optimization at
> intermediate language level is much easier using register-based
> representations.


The .NET and the JVM ILs are meant to be written to disk, sent over
networks, and be usable on many different machines with different word
sizes. While the number of registers on different targets can be
ignored and produce good code, the size(s) of these registers cannot.
Also, there are different kinds of registers on different machines
(floating point/integer on most) and they complicate matters. Are
they just another part of the infinite register file -- a near random
mix of integer and floating point registers of varying size, or maybe
they are all variant.


Also, the infinite number of registers that compilers like gcc think
they have isn't really infinite. It is limited by the word size and
memory limitations of the machine that the compiler is running on. When
run, these compilers typically use a lot of memory for their internal
representations. These internal representations are not usually written
to disk or sent over a communication line in normal use. There are
flags on GCC to make it write it out, but that's really for debugging.
There are others that do write big IRs out, but as far as normal day to
day production use, it isn't usually done, and the IR never leaves the
address space of the compiler. Because it is so big, it is very likely
that many .NET assemblies would too big for many of the .NET target
devices if it were sent that way. It would have to have
indexes/addresses for all of the register accesses, all of the random
RAM accesses, and all of the stack accesses (they would still be there
too). These would all have to be independent and have a large size to
account for the possible values, but as it stands in the JVM class files
(I'm not too knowledgeable on .NET specifics) the only common index is
into the top portion of the stack (only about 256 32bit words deep) so
the only common index is just a byte. Other stuff is indexed through
link time/runtime/just in time name resolution and can be represented in
any manner that the VM running the code wants. It would take a much
bigger IL module to choke it, though.


SSA is great, but it's crazy expensive in terms of memory use. It is
meant to be used for certain types of optimizations and studies of code,
not for being stored in files or sent over the Internet.


I hope my ramblings are helpful and accurate.


Nathan

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