Re: Ravi bug related to setting of L->top in OP_RETURN

[Dibyendu Majumdar <mobile@...>]

On 8 August 2015 at 12:41, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> On 8 August 2015 at 12:00, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>> On 6 August 2015 at 22:55, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>>> It is not only L->top that has a dual purpose; the stack has a dual
>>> usage, due to the way that Lua uses a register-based VM. While inside
>>> a Lua function, Lua preallocates in the stack all "registers" that the
>>> function will eventually need. So, while running VM instructions in
>>> one function, L->top points to the end of its activation record (stack
>>> frame). When Lua enters or re-enters a Lua function, L->top must be
>>> corrected to this frame, except when multiple returns are involved.
>>> In that case, it is true that L->top is used to pass information
>>> strictly between two consecutive VM instructions. (From either
>>> OP_CALL/OP_VARARG to one of OP_CALL/OP_RETURN/OP_SETLIST.)
>>>
>>
>
> I think following illustrate the VARARG case?
>
> VARARG to CALL
>
> function y(...) print(...) end
>
> VARARG to RETURN
>
> function y(...) return ... end
>
> VARARG to SETLIST
>
> function y(...) local t={ ... } return t end
>

And following the CALL case:

CALL to CALL to RETURN

function z1() return y(x()) end

CALL to CALL to SETLIST

function z() return { y(x()) } end

So essentially we can have a chain of these.

The byte code sequence certainly looks beautiful !

Regards
Dibyendu