Re: New project announcement - libjit

On Wednesday 28 April 2004 10:32 pm, Miroslaw Dobrzanski-Neumann wrote:

> Why do you hard wire the enroller in the engine? This *successfully* holds
> *hacker* like me from playing with the code generation.

How are you prevented?  The important thing about libjit isn't really the back 
end anyway.  It's register allocation (local and global), dynamic flow 
analysis, loop unrolling, method inlining, etc.  All of those should be done 
in the generic core, with only a few platform-specific definitions.  Very 
little work has been done on this yet, so there are plenty of opportunities 
for clever programmers.

> Few months ago I have played with the register allocation optimization in
> the pnet enroller (using all cpu registers and tracking their usage).
> Finally I gave it up after I realized that the integration into hardwired
> enroller code is a hopless task.

libjit isn't like that.  85-90% of the work is done in the common code, with 
only final code expansion in the CPU-specific bits.  That x86 and ARM back 
ends already try to use all registers, but they do it by providing config 
information to a common register allocator (in jit-reg-alloc.c), rather than 
having several allocators, one per CPU.  That's how gcc works too, BTW.

With the new design, there would be little benefit in having several back ends 
for the same CPU.  However, there may be special-purpose customisations.  
e.g. using MMX registers for 64-bit operations on CPU's with MMX, or using 
CMOV to optimize away branches.  But that would be an option in the x86 back 
end, rather than a separate back end.

There's nothing preventing you from investigating these things.  I'd welcome 
it, as it would free me up for other structural design work.

Cheers,

Rhys.