Re: Lua parser question re function calls in local statement

[Dirk Laurie <dirk.laurie@...>]

2015-01-17 4:12 GMT+02:00 Dibyendu Majumdar <mobile@majumdar.org.uk>:
> Hi,
>
> For following Lua code:
>
>  local d, e = f()
>
> The byte-code generated looks like:
>
>         1       [1]     GETTABUP        0 0 -1  ; _ENV "f"
>         2       [1]     CALL            0 1 3
>         3       [1]     RETURN          0 1
>
> And for following:
>
>  local d, e; d, e = f()
>
> We get:
>
>         1       [1]     LOADNIL         0 1
>         2       [1]     GETTABUP        2 0 -1  ; _ENV "f"
>         3       [1]     CALL            2 1 3
>         4       [1]     MOVE            1 3
>         5       [1]     MOVE            0 2
>         6       [1]     RETURN          0 1
>
> My question is this:
>
> I want to change the code generated for the first case - to capture
> the return values from the CALL into temporary registers and then MOVE
> them to the locals. I think I need to make changes in localstat()
> function in lparser.c but I can't figure out how to do this - would
> appreciate any help / tips.

There is no difference between temporary registers and locals.
A local variable is simply a stack slot for which the compiler has
a name. Not all the names are visible at the Lua level.

All the "local" instruction does ia give names to slots and
increment the count of how many locals there are.

The reason for the difference between the two sets of code
is that in the first case when you give names for the two stack
slots, the compiler knows they already have the values in them,
so no need to move anything. I.e. the '=' in a local instruction
generates code only when the most recent temporary slots
do not already contain the required values.

Do yourself a favour: list your bytecode with `luac -l -l` and
carefully study the result. Try some examples with several
'local' statements, with code in between, and for functions
that have upvalues.

BTW, not relevant for this thread but useful to bear in mind,
the VM works on one side of the stack, the C API on the other.