Higher constant limit in Lua 5.2 Alpha

[Joshua Jensen <josh.jjensen@...>]

I've been staring at this code for a while in an attempt to backport it 
to Lua 5.1.  It should be doable, but I have a 
performance/implementation question.

luaK_codeABxX() is only used to generate the opcode OP_LOADK.  When 
luaK_codeABxX() encodes the constant, it chooses one of two routes:

* When the constant index fits in the OP_LOADK instruction, it adds one 
to the constant index and then stores a single instruction.
* When the constant index exceeds what will fit in the single 
instruction, an additional instruction, OP_EXTRAARG, is used to encode 
the extra size.  The 'constant' stored in OP_LOADK is 0 and is used as 
an indicator to grab the extra size from the following OP_EXTRAARG 
instruction.

OP_SETLIST uses the index of 0 to look up the larger constant index in 
the next instruction.  OP_SETLIST instructions are run infrequently.

OP_LOADK, an instruction called frequently, now runs the following code:

    #define KBx(i)  \
      (k + (GETARG_Bx(i) != 0 ? GETARG_Bx(i) - 1 : 
GETARG_Ax(*ci->u.l.savedpc++)))

This is in contrast to Lua 5.1's simpler k+GETARG_Bx(i) that doesn't 
require a comparison check and a branch:

    #define KBx(i)    check_exp(getBMode(GET_OPCODE(i)) == OpArgK, 
k+GETARG_Bx(i))

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.

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?

Thanks.

Josh