Related articles |
---|
CIL question stefan.mandel@iese.fraunhofer.de (Stefan Mandel) (2006-01-19) |
Re: CIL question lupus@debian.org (Paolo Molaro) (2006-01-20) |
Re: CIL question DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-01-20) |
Re: CIL question stefan.mandel@iese.fraunhofer.de (Stefan Mandel) (2006-01-26) |
Re: CIL question anton@mips.complang.tuwien.ac.at (2006-01-28) |
Re: CIL question lupus@debian.org (Paolo Molaro) (2006-01-28) |
Re: CIL question DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-01-28) |
Re: CIL question nathan.moore@cox.net (Nathan Moore) (2006-01-28) |
From: | Hans-Peter Diettrich <DrDiettrich@compuserve.de> |
Newsgroups: | comp.compilers |
Date: | 28 Jan 2006 15:17:00 -0500 |
Organization: | Compilers Central |
References: | 06-01-065 06-01-068 06-01-076 |
Keywords: | interpreter, code |
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
precompiler.
> 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
> representations.
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?
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.