[Mono-list] Future of JIT

[Paolo Molaro]

On 02/02/03 Ilya Minkov wrote:
> Have you considered VCODE/ICODE to become a basis for your JIT backend?

Yes.

> 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 

x86 has 90+% of the market share, so if there is no good support for x86
it's not good enough:-)
The main problem with vcode is that it has a high-level approach,
but to implement efficiently many of the opcodes needed by the CLR, we 
need direct access to the CPU features: as an example, you may want to
use vcode to implement the addition of two int64 values. How does
the generated code look like on x86, ppc, sparc? How does the C code to
produce it look like? What about the variant with overflow detection?

> The thing to check: *licensing issues* (?), i don't know under which 
> condition it has been licensed.

vcode is not free software, so it could not be used in mono, even if it
was technically good for us.

> 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 

Ugh, maybe for RISC instruction sets it's easy and fast, but what about
the x86 instruction set? It would be a complete pain to implement.

lupus

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