[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua parsing question
- From: Dibyendu Majumdar <mobile@...>
- Date: Mon, 24 Feb 2020 22:45:11 +0000
On Mon, 24 Feb 2020 at 19:46, Dibyendu Majumdar <firstname.lastname@example.org> 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(), y, z = f()
> Here x() 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.
In x() - the instructions for x() will be emitted during the
'var' phase, but the final temp = value will be emitted during the
Also the stores happen in reverse order.