Re: Higher constant limit in Lua 5.2 Alpha

[Roberto Ierusalimschy <roberto@...>]

Without deeply understanding this, I wonder about the implementation
of an extra opcode, OP_LOADKLARGE.  This opcode would assume the size
is stored in the next instruction.  It could even combine bits from
the current instruction and the next instruction.  OP_LOADK would be
stored as per Lua 5.1.  Lookups would not need comparison checks.

We would need some real data to be sure, but this seems a small
overhead. The test does not need extra memory accesses (GETARG_Bx(i)
must be computed anyway) and it is correctly predicted most of the time.
(Nevertheless, the separation might be a good idea independently of
performance gains.)


> I was also wondering about the need for an OP_EXTRAARG at all.  In
> its current form, the '0' index is understood to mean OP_EXTRAARG
> follows.  Why not devote all bits of the 'instruction' to the data?

We had this experience before. It makes the bytecode harder to check.
Lua 5.2 does not have this check, but there are people working on the
subject. (I hope we will not have many problems with the new limit
of 2^26 constants. On Windows that means a constant table with 1GB.)

-- Roberto