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 internalcalls. > > 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. 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:-) lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
