lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Sun, Nov 15, 2020, 03:31 Egor Skriptunoff <egor.skriptunoff@gmail.com> wrote:
On Sun, Nov 15, 2020 at 12:30 PM David W wrote:
I don't think that with just this set of ranges and these opcodes, you can algorithmically deduce that (say) local e is assigned to register 2.

The algorithm:
at the start of "lifetime" of new local variables their VM registers are numbered sequentially starting from the first unused VM register.
At the instruction #11 (the start of "lifetime" of variables d,e,f) the VM registers 0-2 are already unused because the previous variables holding these registers (a,b,c) are out of scope (their "lifetime" has ended at instruction #2).

I see! This relies on the simplicity of Lua's code generation, specifically that temporary registers never have a lifetime longer than a single _expression_. It requires an O(N) loop to basically redo the register assignment in the debugger/decompiler, without ever looking at the instructions.

I think there may actually be a constant-ish time algorithm, now that I've thought about it some more: the register for a local is the destination register of the instruction that assigns it, which is usually immediately before the start of its lifetime. However, if the next N locals share the same startpc, then you have to subtract N from your calculated register. And function params are a slight special case, since there is no instruction that assigns them.