Re: Bug in Lua code generator

["Rici Lake" <lua@...>]

Roberto Ierusalimschy wrote:

> OP_UNM does not accept constants
> because that would make the instruction slower in the general case
> only to optimize the most improbable case of negating a literal string
> (e.g., -"123"), as negating numeral constants are done at compile time.

Yes, I thought that it might be an optimization, but it's hard to believe
that it's much of a win; a CPU with branch prediction should get the
branch right all the time anyway.

Conversely, if it is a significant optimization, that would suggest that it
might be better to move the K bits from operand to opcode, making the
Instruction 8/8/8/8 instead of 6/8/9/9. If my count is right, this would
actually increase the number of opcodes by 35, but the implementations
of the additional opcodes are small and it would probably only increase
the size of the VM by a little.

In fact, if the K versions of the binary opcodes were only used
for numeric constants, then the KB-KC variants would be
unnecessary and the extra opcodes would just fit into the
existing six bits, and furthermore a number of ttisnumber()
tests could also be avoided.
>
>
>> The solution would be either to make OP_UNM accept RK(B) instead of just
>> R(B), or to change the test in line 702 of lcode.c to include VNIL,
>> VFALSE
>> and VTRUE
>
> Maybe it would be better to reverse the test?
>
>      if (!isnumeral(e))
>        ...

That seems reasonable. In fact, simply:

    if (e->k != VKNUM)
      ...

should be sufficient, since the rest of the tests will occur in
later code branches.