¿El bytecode de Can Lua para las declaraciones 'if' salta hacia atrás?

Question

Estoy escribiendo un código Lua que puede leer el bytecode producido por la función string.dump(). Asumo (debido a que permite algunas optimizaciones y menos codificación) que todas las instrucciones OP_JMP aumentan el puntero de instrucción hacia adelante cuando se usan para sentencias if. Técnicamente podrían saltar hacia atrás porque usan el valor sBx (que puede ser negativo). Solo me interesa el bytecode de las declaraciones if de la implementación estándar de Lua 5.1.

Utilicé chunkspy (herramienta asombrosa por cierto), para mirar el bytecode para algunas muestras.

Aquí es un básico sentencia if:

a, b = 1, 2 
if a == b then 
    print '=' 
elseif a < b then 
    print '<' 
else 
    print '>' 
end 

Produce cuatro saltos, ninguno de los cuales son negativos:

[08] jmp 4; to [13] 
[12] jmp 11; to [24] 
[16] jmp 4; to [21] 
[20] jmp 3; to [24] 

he intentado buscar respuestas en el Lua source code, pero simplemente terminó ser confuso (estoy seguro de que es un código súper elegante si me tomo el tiempo de entenderlo).

¿Alguien sabe de un caso para declaraciones 'if' donde la instrucción OP_JMP de lua tiene un valor negativo para sBx o saber si son siempre valores positivos?

Answer 1

Respuesta corta: las instrucciones IF no pueden generar JMP negativos (en cualquier compilador optimizado, idioma independiente). Lua OP_JMP puede ser negativo para los bucles y sentencias goto (http://lua-users.org/wiki/GotoStatement)

Respuesta larga: Esto se debe al hecho de que un salto de retroceso sólo se genera por cualquier compilador si se necesita repetir cierto código que ya traducido (para, mientras bucles ..). Si pasa a una instrucción IF "nueva", siempre colocará un JMP condicional y el código/bytecode resultante como las siguientes instrucciones.

Por otro lado, un compilador "extraño" puede producir saltos FI negativos. Pero eso no tendrá sentido. Para tener un IF JMP negativo en una ubicación determinada, uno ya debe haber omitido esa misma ubicación en el pasado (por un JMP positivo), por lo que no se puede optimizar el código en términos de velocidad de ejecución.