Re: [Lightning] Code patching, context switching

[Sandro Magi]

On Wed, Feb 20, 2008 at 12:19 PM, Paolo Bonzini <address@hidden> wrote:
>
>  > That's unfortunate. Is there a good reason for this artificial
>  > limitation? Seems Lightning would be much more flexible as a code
>  > generator with a low-level interface, which is what I assumed
>  > JIT_R/V/FPR were, and a higher-level interface, which is what
>  > jit_getarg and jit_prolog are. I can understand wanting to insulate
>  > the users from inadvertently clobbering the argument registers, but a
>  > low-level api would still be nice.
>
>  The problem is that jit_pusharg needs to clobber r3-r9, and it would be
>  an unnecessarily complication to say "this and that JIT_Rx register" are
>  clobbered by jit_pusharg, but only on this and that architecture".

Yes, that's what I meant, which is why I suggested a nested API. The
ideal structure in my mind, is a full "Hardware Abstraction Layer",
and a simple template API built on it. The simple API consists of
using prolog, getarg, and pusharg, but not exposing any registers. The
user thus deals only with "variables", and this simple API uses a
naive linear register allocation expressible via macros. For instance,
on every pusharg, increment the last allocated register by one, then
wrap once you reach JIT_R_NUM, and push JIT_R(0) on the stack. Pusharg
can even accept an additional parameter as a hint (like C's 'register'
storage class), to help it determine whether to allocate it to a
register, or push it on the stack.

The low-level API then exposes the full register set for those who
actually want to generate their own code. I think this achieves the
optimal balance between ease of use, and flexibility. What do you
think?

Sandro