[Mono-list] Announce: A .NET assembly -> native code generation
tool (ala ngen for MONO)
29 Jul 2002 14:15:33 +0200
On Mon, 2002-07-29 at 12:34, Paolo Molaro wrote:
> On 07/29/02 Dietmar Maurer wrote:
> > 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.
> As long as the native code doesn't handle exceptions, the only info
> needed is registering the method code address and size, there is no need
> to save/restore the LMF, right? I saw the code that uses objdump, so
> maybe this is already handled.
> Actually, if this turns out to work, we may want to use it also for the
Ok, if we trust such code we can use the objdump hack. Although
restoring the registers is still a big hack.
> > > 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 think the approach of using gcc is certainly interesting even if the
> first snapshot has limitations.
> The primary purpouse of ngen-ed assemblies is to reduce startup and JIT
> costs (microsoft itself documents ngen-assemblies being slower code-wise
> than jitted code...). Of course, performance is an bonus:-), but I'm
> very impressed with the first snapshot.
> The gain in mcs compilation times, for example, seems to match
> pretty well with the jit overhead as measured with mono --profile.
> And, of course, mcs is not a good benchmark for native code quality.
> Of the current limitations, the .ovf opcodes seems only a matter of
> (boring) programming, mostly. The exception handling stuff is certainly
> harder and if done using the C++ exception tables, it will
> require porting efforts between different compilers. However, I just
> checked and methods with exception tables are less than 7% in mcs and
> less than 2% in corlib, so even if 5% of the methods still need to be
> jitted, it's not a big problem.
good news ;-)
> My main concern with using gcc is that we might not be able to constrain
> the gcc optimizer to obey the CLR rules (Zoltan notes the problem with
> division by 0, for example). Using the JIT to output the code would give
> us better control on such issues, but researching these issues is the
> only way to find out if the concept works:-)
So I think everybody agrees that it would be nice to have a native code
generator, so integrating that code into the sources should be the goal.
All I am concerned about it to avoid code duplication, which makes it
hard to maintain that code. I would like to share as much code as
possible with the JIT.
Unfortunately the current patch is much to large to integrate. What we
need is a bunch of smaller patches which we can integrate into our