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

[Paolo Molaro]

On 07/29/02 Dietmar Maurer wrote:
> > 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
> > internalcalls.
> 
> Ok, if we trust such code we can use the objdump hack. Although
> restoring the registers is still a big hack.

I didn't consider the register problem in my reply, so, unless we find a
nice solution for it, we may not be able to use the hack for icalls.
Using it for ngen-ed assemblies is less of an issue, because we could
check that the compiled methods obey the assumptions in the code before
installing the native lib in the GAC: this can't be easily done for
icalls.

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

I'm not advocating the integration of the patch right now.
Let's first experiment with it a bit, and see if we can find a solution
to the primary issues:
1) make sure we can get gcc to obey the rules of the CLR
2) try to remove the assumptions on the gcc code layout

The first is a correctness issue and is the most important.
The latter is a maintainability issue that I would like to find a
solution for (and it would allow us to enable scheduling in gcc).

About the code duplication issue, let's try to discuss with Zoltan what
is the best approach to the problem: some parts of the code are
certainly needed also if/when we use the JIT to precompile the
assemblies, for example.

Some other issues would need to be resolved in the code like the linking
phase, so we could get it to work for multiple app domains while keeping
the mmapped pages read-only.
I think the gcc approach may give good results, just let it still mature a
bit.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better