[Mono-list] Future of JIT

[Ilya Minkov]

Have you considered VCODE/ICODE to become a basis for your JIT backend?

It was developed/used for runtime code generation in Tick C Compiler, which is in turn based upon LCC. And since its command set is tuned for LCC, it should also fit the .NET architecture if i'm not wrong. I haven't read many important papers because of lack of time, so don't consider what i tell here sole truth, it can have rumors/ misconceptions/ stuff mixed in.

It has been well ported to all (widespread) RISC CPUs, and there is a half-broken x86 port. I have been intending to make a "real" x86 port for use in some project of mine. But i think MONO could be a better use for me, and i would like to be of use if i have time and our targets match.

VCODE is a set of C macros, generating target machine code out of the generalized RISC set without intermediate representation, like GNU Lightning does. With a difference that GNU Lightning is broken.

ICODE is a form of binary representation for VCODE, which also integrates a number of generic optimisations and register allocation, reaching considerable execution speeds.

The thing to check: *licensing issues* (?), i don't know under which condition it has been licensed.
- checked already. It's "fair use" - not to sell, else use as desired, retain copyright. It even allows usage in commercial products but it doesn't matter.

I think the system should be as staged as possible, so that only a minor part should be ported to another architecture, and that improving some actually platform-independant stuff wouldn't break some platform while leaving others working. Besides, this VCODE already contain a lot of work done by others.

I also think that it should be possible to attach a peephole optimiser to VCODE. Any time a label is issued, if optimiser is enabled, it would disassemble (simplified, extracting a minimum of information) all the code generated since the last label, and write "tags", noting where each CPU command starts and some basic properties of it, like LCC-Win32 does it. Then, peephole optimisation is basically pattern-matching and disassembling certaing commands as this information is needed, and so on as usual. Finally, the last label should be moved back.

Then i think, compilation should be "lazy". The first time a function is compiled, it is done the fastest way, optimising nothing. Functions which it requieres are not compiled. Inputs are placed on stack as usual, but with a CALL to some (assembly-written) dispatcher function. This dispatcher when called does the folowing:
- Looks at return adress. Using that, finds out what function exactly is to be called in this place. (This information needs to be generated when compiling that original function)
- If the function to be called is already compiled, then change the call adress (which is just placed before the return adress) with the actual function adress to be called, and call this function, then return.
- If the function is not yet compiled, compile it, then procede as in previous case.
The next time a function will call another function directly

First time a function is compiled it is compiled without optimisations. I guess it would be OK to place a call to counter in the beginning of such a function - since it's not compiled for speed...
As soon as this counter decides that the function has been called "often enough", it should recompile the function with all optimisations on, this time without embedding the counter. The system to replace adresses might either be the same as previous, or more a more rapid one so that the unoptimised function can be deleted at once.

Of course, there can just as well be multiple optimisation steps, but it might be the next step.

Opinions?

-i.

_______________________________________________
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list