You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The CALL instruction currently takes an arbitrary number of arguments and copies them into a new stack frame. We could adopt a Lua-style calling convention where switching to a new stack frame requires only moving the base pointer up. Unfortunately, Lua uses a separate stack to store the activation frame info (like the return address), while LuaJIT 2 relies on the fact that pointers only take up 32 bits while all values take up 64 bits.
We can work around this by explicitly clobbering a register: CALL r4(r5,r6,r7) is encoded as: CALL 4,4 followed by pointer info. It will have the following stack effect:
That is values in r0, r1, r2 will survive across the call, but r3 is clobbered. It will be used either to store the return address (the saved value of the base pointer can be derived from the instruction preceding the return address) or it can be used to store a pointer to some meta data.
Register r4 will become the Node pointer (=r0) in the called function, and the remaining registers will become the function arguments.
The main difficulty with this approach is that the register allocator needs to move all live values into the lower registers to minimise the size of a stack frame. This may require more sophistication than we really want. (OTOH, the current mechanism of just copying everything into a new frame is also very wasteful.)
The text was updated successfully, but these errors were encountered:
The CALL instruction currently takes an arbitrary number of arguments and copies them into a new stack frame. We could adopt a Lua-style calling convention where switching to a new stack frame requires only moving the
base
pointer up. Unfortunately, Lua uses a separate stack to store the activation frame info (like the return address), while LuaJIT 2 relies on the fact that pointers only take up 32 bits while all values take up 64 bits.We can work around this by explicitly clobbering a register:
CALL r4(r5,r6,r7)
is encoded as:CALL 4,4
followed by pointer info. It will have the following stack effect:That is values in
r0
,r1
,r2
will survive across the call, butr3
is clobbered. It will be used either to store the return address (the saved value of thebase
pointer can be derived from the instruction preceding the return address) or it can be used to store a pointer to some meta data.Register
r4
will become theNode
pointer (=r0
) in the called function, and the remaining registers will become the function arguments.The main difficulty with this approach is that the register allocator needs to move all live values into the lower registers to minimise the size of a stack frame. This may require more sophistication than we really want. (OTOH, the current mechanism of just copying everything into a new frame is also very wasteful.)
The text was updated successfully, but these errors were encountered: