Re: CIL question

Stefan Mandel <stefan.mandel@iese.fraunhofer.de>
26 Jan 2006 14:14:30 -0500

          From comp.compilers

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)
| List of all articles for this month |

From: Stefan Mandel <stefan.mandel@iese.fraunhofer.de>
Newsgroups: comp.compilers
Date: 26 Jan 2006 14:14:30 -0500
Organization: Fraunhofer Gesellschaft (http://www.fraunhofer.de/)
References: 06-01-065 06-01-068
Keywords: code, design
Posted-Date: 26 Jan 2006 14:14:30 EST

Hello,


Paolo Molaro wrote:
> 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 was a third party comment. The author wanted to distinguish the Java
VM and the .NET VM. I have found similar statements from other third
party people.


> CIL code is meant to be compiled, but this doesn't mean that it must be
> compiled.


Now this holds for any language, doesn't it. But perhaps this was the
reason for my misunderstanding.


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


That is a good point ... I will think about it. But I am not yet convinced.


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


Most optimizing compilers translate the source language to an
intermediate representation with a infinite number of registers (e.g.
SSA code). Optimization and register allocation should be quite
efficient with this IR. I also think, that the Java VM as well as the
.NET VM internally work (in JIT-mode) on SSA-based intermediate
representations.


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.


Regards


Stefan


Post a followup to this message

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