Re: [Lightning] Support for an "automatic area" on stack

[Ludovic Courtès]

Hi,

Paolo Bonzini <address@hidden> writes:

>>   /* Prolog of a 3-arg function, with 8 octets reserved on the stack.  */
>>   jit_prolog_with_stack_area (3, 8);
>>
> We can have instead jit_allocai or something like that, which could
> either do a JIT_SP subtraction or patch the save instruction on the
> SPARC.

Yes, this looks nicer!

> I don't remember the details for leaf functions on the sparc.

Actually, a leaf function should probably not touch the current frame at
all because otherwise the caller would end up stuck (the leaf may have
overwritten its caller's local variables since the leaf cannot know how
large its caller's local variable area is).

> This I'd rather avoid.  The i386 has an undocumented JIT_FP macro, we
> could provide something similar for other architectures.  My
> preference would be something like
>
>    jit_ldxi_p (regd, JIT_FP, offset)
>
> but I could live with
>
>    jit_ldxi_p (regd, JIT_FP, jit_auto (offset))
>
> or
>
>    jit_ldxi_p (regd, JIT_FP, JIT_AUTO_BASE + offset)
>
> (Note that I don't like neither jit_auto nor JIT_AUTO_BASE, but this
> is just a proof of concept).  JIT_AUTO_BASE could access the global
> state in _jit, so it it is exactly as powerful as jit_auto.

Aren't there arches where local variables are addressed relative to %sp?

If this is the case, then we really need a special macro that hides away
the use of either %sp or %fp.

Similarly, even if all arches address local vars relative to %fp, then
we should check whether they all address them as negative offsets
relative to %fp (as is the case on SPARC).  If the answer is "no", then
the first and second variants that you proposed won't work.

Thanks,
Ludovic.