Instructions with bitwidth-dependent operands
Some instructions assume a 32-bit interpreter. For instance, the (new) ABC instruction pop_b_rtn
pops a number of elements from the B-stack and returns. The instruction pop_b_rtn 1
is translated into the bytecode [411, 4]
where 4
is the translation of 1
. The semantics is 'pop 4 bytes', however, that depends on the bitwidth of the interpreter. I think it would be better to encode this as [411, 1]
with the semantics 'pop 1 element'. This is a performance issue, we would then have to change this to 4/8 when parsing the bytecode in the interpreter to avoid having to multiply the value at runtime.
There are probably many more instructions affected by this. Here is an alphabetic, possibly non-exhaustive list (please add more when you find them, so that we can fix them once we make a decision):
-
pop_a -
pop_a_jmp -
pop_a_jsr -
pop_a_rtn -
pop_ab_rtn -
pop_b -
pop_b_jmp -
pop_b_jsr -
pop_b_pushBFALSE -
pop_b_pushBTRUE -
pop_b_rtn -
updates2_a_pop_a (to be done when we meet a program that uses it)
In the relevant branch:
-
The bytecode generator has been adapted to not perform the optimisation. -
The interpreter has bitwidth-independent code (possible because we add the value to a pointer). -
This is inefficient, because we need a shl
instruction on every affected codeword. The optimisation must be added to the parser (for which we need #5 (closed) and an intelligent parser [#9 (closed)]).