Re: [Lightning] RFC: Proposal for lightning 2.0

[Ludovic Courtès]

Hi,

Paulo César Pereira de Andrade
<address@hidden> skribis:

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

[...]

>> 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.

I see.  That’s a noticeable change in spirit.

It’s probably worth checking what its main “customers” would think,
particularly GNU Smalltalk and Racket.

>> 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.

This sounds like an API detail, no?

My concern is that lightning would get more weight, while not being on
par with libjit.

To put it differently, lightning and libjit currently fill different
niches, but that change would seem to put them in the same niche.

>>> * 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.

OK.

Thanks for explaining!

Ludo’.