[Mono-devel-list] Re: proposal for a different JIT

Emanuele Ruffaldi pit at sssup.it
Thu Oct 16 04:02:24 EDT 2003

Paolo Molaro Wrote:

>It is an interesting idea and probably a worthy argument for a student
>doing a thesis on it, but I'm not sure it is as easy as you think it
>will be (or practical due to the speed issues and the huge work I think
>would be needed to make it work correctly).

I now there are some issues, specially how many tool invocations (ksi-as-ld) are needed
and the way the output is generated. Another problem is the number of shared files generated.
For example under Windows is possible to load a DLL using custom loaders reducing the overhead of the LoadLibrary
function, and more, with the possibility to delete the file after the loading, I'd like to know if this
is possible under Linux/Unix.

>I don't know what kind of abstraction on the hardware the gcc backend
>provides, but IL code demands much more bare-metal knowledge than, say,
>C, C++ or java. So, getting the backend to produce correct code likely
>requires adding new features to it and port them to the different
>platforms (for example, check the .ovf variants of some opcodes, or the
>handing of NaNs required when comparing floating point numbers etc.).

The actual KSI implementation is quite flexible and for example the following
is an exported function that defers a pointer and returns the value.

 (func .public .int32 myfx []"
    (bind (compound ["
      (return (modify (result) (indirect (const (ptr (int 32))0x100202))))]))) 

>Getting a prototype working may be easy, but I think it will be hard to
>provide the level of compatibility the CLR requires across the different
>Another issue may be the need to constrain the optimizations gcc
>performs to keep the semantics of code correct: I don't know if the gcc
>backend provides any facilities to encode such constraints. Exanples
>*) some operations may have side effects unknown to gcc (like the
>raising of an exception with a division by 0)
>*) code reordering and hoisting needs to be constrained to keep
>the order of possibly implicit exceptions constant

Yes, actually the main problem is the exception checking, but there are a lot of
front ends (like the ada one Ada) that checks for overflow or fine grained exceptions.
I could investigate the problem of the implicit exceptions before proposing again this


More information about the Mono-devel-list mailing list