Re: Lua parsing question

[Dibyendu Majumdar <mobile@...>]

On Mon, 24 Feb 2020 at 19:46, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>
> Tidbits of Lua parser / code generator for folks that find such things
> of interest.
>
> Lua is ostensibly a register VM. However there is a problem generating
> code for a pure register machine because of the semantics of Lua
> function calls. Lua functions can return unbounded multiple values -
> in theory filling up stack space. So the only way to allocate
> registers is to follow a stack discipline, with only one 'open' call
> possible at the top of the stack.
>
> Lua's suffixed expressions can be l-values or r-values, and it is not
> known until later what it should be. Example:
>
> x()[1][2], y, z = f()
>
> Here x()[1][2] is an l-value as it is going to be ultimately assigned to.
>
> The parsing and code generation of assignment statements is IMO one of
> the trickiest aspects of Lua, another being the handling of multiple
> return values. Lua solves the l-value / r-value dilemma by deferring
> the resolution of these expressions until the expression is used -
> hence the VINDEXED expression type can end up being a GET or a PUT.
>
> The parsing of assignments follows a strange course. I believe the
> vars on the left of '=' are parsed recursively first, then at the top
> of recursion, the expression list to the right of '=' is parsed, and
> then during the unwind, the store instructions get generated. Please
> correct me if I am wrong.
>

My description above is inadequate. The parsing includes code
generation as well except that the final operation (GET or PUT) is not
resolved until the store or load happens.

To clarify:

In x()[1][2] - the instructions for x()[1] will be emitted during the
'var' phase, but the final temp[2] = value will be emitted during the
unwind phase.
Also the stores happen in reverse order.