[Mono-list] Announce: A .NET assembly -> native code generationtool (ala ngen for MONO)

[Zoltan.2.Varga@nokia.com]

					Hi,

> -----Original Message-----
> From: ext Dietmar Maurer [mailto:dietmar@ximian.com]
> Sent: 29. July 2002 10:47
> To: Miguel de Icaza
> Cc: Varga Zoltan.2 (NMP/Budapest); Mono List
> Subject: Re: [Mono-list] Announce: A .NET assembly -> native code
> generationtool (ala ngen for MONO)
> 
> 
> On Sun, 2002-07-28 at 06:03, Miguel de Icaza wrote:
> > Hello Zoltan,
> > 
> > >    The first version of my ngen clone for MONO is available at:
> > > 
> > > http://www.nexus.hu/vargaz2
> > 
> > This announcement is of course really exciting.  I have only taken a
> > very superficial look so far at the code generator, but the 
> approach is
> > a very interesting idea.  I will let Dietmar and Paolo 
> comment further
> > on it.
> 
> wow, about 6000 LOC! I have not looked into every detail, but i think
> this approach has some problems:
> 
>         1. It does not work with exceptions: The current code is
>            incorrect because it does not save/restore the LMF when
>            calling precompiled methods - but saving/restoring the LMF
>            would lead to serious performance problems.

Can you explain what the LMF is? I looked at the code, but I can't understand what it is.

BTW: I started this as a hobby project to learn about .NET/compilers etc. I wouldn't be suprised if it turned to be unusable
due to problems such as the one above...


>         2. Array bound checking: There is no array bound 
> checking at the
>            moment and maybe that is the only reason why it speeds up
>            pnetmark? gcc is unable to do bound check removal, so array
>            access will be slow (or you have to remove that 
> checks before
>            you emit C code).

You are right. I somehow throught that mono does not do bound checking (perhaps an earlier version didn't) so I put that
on the TODO list instead of implementing it right away.


>         3. I wonder if gcc is really able to optimize the emitted C#
>            very much.
> 

gcc is designed to optimize procedural code, so of course it has problems with virtual calls, bound checks, delegates etc. 
But every program contains a mix of high level and low level code, so some performance gains can be expected ever for
programs written in an object-oriented style such as mcs.

> > What I wanted to look into was to use the JIT to generate code that
> > would end up in a library, basically reusing the JIT, but 
> turning on all
> > the optimizations for this.
> 
> This approach would also avoid much code duplication.
> 
> So IMO we should first check if we gain anything by using gcc, and of
> course we need a solution for the exception problem?

I started this as a hobby project to learn about .NET/compilers etc. I wouldn't be suprised if it turned to be unusable
due to problems such as the one above...

> 
> - Dietmar
> 
> 
> 

						bye

							Zoltan