|CIL question email@example.com (Stefan Mandel) (2006-01-19)|
|Re: CIL question firstname.lastname@example.org (Paolo Molaro) (2006-01-20)|
|Re: CIL question DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-01-20)|
|Re: CIL question email@example.com (Stefan Mandel) (2006-01-26)|
|Re: CIL question firstname.lastname@example.org (2006-01-28)|
|Re: CIL question email@example.com (Paolo Molaro) (2006-01-28)|
|Re: CIL question DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-01-28)|
|Re: CIL question firstname.lastname@example.org (Nathan Moore) (2006-01-28)|
|From:||Hans-Peter Diettrich <DrDiettrich@compuserve.de>|
|Date:||28 Jan 2006 15:17:00 -0500|
|References:||06-01-065 06-01-068 06-01-076|
|Posted-Date:||28 Jan 2006 15:17:00 EST|
Stefan Mandel wrote:
> 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.
Yes, we speak of different things. I addressed precompilers, i.e. the
source to CIL compiler, whereas you address compilers into native code,
which in the case of .NET are the JIT compilers.
> 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).
And that number is only known to the JIT compiler, not to the
> I yet do not know how to map stack code (might work too)
Every cell in the stack is equivalent to a register. Keep track of the
stack pointer, to obtain the register number from the relative offset.
Optimization is not required, because everything beyond the actual stack
pointer is known to be never used any more.
> and I am convinced that optimization at
> intermediate language level is much easier using register-based
Exactly *what* do you want to optimize?
An optimization of an infinite number of available registers doesn't
make sense, and the optimization of the physically available registers
is only done in the JIT compiler. So what?
Return to the
Search the comp.compilers archives again.