Re: [Lightning] RFC: Proposal for lightning 2.0

[Paulo César Pereira de Andrade]

2012/11/26 Ludovic Courtès <address@hidden>:
> Hi,

  Hi,

> Congratulations!  ;-)

  Thanks :-)

> Would lightning remain an everything-in-header kind of tool, or would it
> require linking against a library?

  It needs to be a library mostly due to the IR, with real functions instead
of all in preprocessor macros, it is easier to write more readable code,
as well as only export what really is supposed to be visible.

> Also, how would you position lightning 2.0 compared with GNU libjit?  I
> think there has to be a clear message.

  Both use a different approachs. Main difference is that libjit uses an
abstract "jit_value_t" that can be a register or constant, while in lightning
the programmer must know if using a register or constant.

>> * There is a simple register allocation scheme. One can make a register
>>   global by calling jit_get_reg(flags) where flags is a specific register
>>   name and never call jit_unget_reg(reg), but the most common usage
>>   is to allocate a temporary register. It is advisable to have only one
>>   global register (using a callee save register) and only have more than
>>   one temporary based on knowledge of number of registers; not a
>>   problem to use a lot of temporaries in mips or ppc, but an issue
>>   in i586.
>
> Is there a limit on the number of registers that can be created?

  It is mapped to the number of usable hardware registers, lightning
itself should not use any global register. The only condition it would
ever fail is if one attempts to allocate more registers than there are
hardware registers, but it is advisable to ensure there is at least
one general purpose register free all the time, or it may generate
a lot of spurious spills.

  Besides need for having code conditioned to number of available
registers (or use only 3), it may be better to know what a register
maps to in case of special purpose registers, and avoid the need
of a temporary register to save a value, that is, for example, if
generating jit for x86, and generating a shift, ensure the shift
argument is in *CX. If using the return value of a function, use the
register where the value is returned. There is no register renaming
optimization (but a simple one for common cases can be added).

> For register-based VMs (like Guile’s future VM), it sounds like an
> extremely useful feature if users can just allocate new registers and
> let the allocate DTRT.

  It cannot handle very well register with a short lifespan but that must
cross basic block boundaries, but as long as it does not need to
jump over too many labels, or is not in loop, the register allocator
should do fine, does no fail, just will defensively assume the register
is live possibly for too long.

> Thanks,
> Ludo’.

Paulo