lua-users home
lua-l archive

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

As well the code t[a+2] would definitely generate several opcodes to compute a+2 before using it as key in GETTABLE R(A), R(t), R(a+2), where R(t) is the register holder the table t, and R(a+2) is the register containing the computed value of key (a+2)...
The only limit is syntaxic and the semantic we want to apply to that syntax "t[1, 2]". The opcodes in the LuaVM is definitely not an issue.

Le dim. 9 déc. 2018 à 23:15, Philippe Verdy <> a écrit :
op codes are not an issue at all here; there's still a sequence of opcodes possible to compute RK(C) in a register mapping the expected key from the pair.
Even the code "t[1][2]" would also generate a sequence (GETTABLE;SETTABLE) or (GETTABLE,GETTABLE) and not a single opcode...

Le dim. 9 déc. 2018 à 20:47, Dibyendu Majumdar <> a écrit :

On Sun, 9 Dec 2018 at 18:12, Dirk Laurie <> wrote:
> 1. Is there any syntactic reason why one can't patch Lua so that
> t[1,2] won't raise a compilation error, but instead invoke
> __index(t,1,2) or __newindex(t,1,2,v)?

I think there are issues with the way the table op codes work - and
the number of registers they allow.

GETTABLE A B C   R(A) := R(B)[RK(C)]

The opcode doesn't have room for additional registers.

Lua's parsing also assumes that there is a single register for the key.