You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each instruction is 32-bits, and has an 8-bit opcode, and 3 8-bit fields (a, b, c).
Instructions use just one of these fields to index into the registers on the stack, and the local constants table, which limits the maximum addressable registers and constants.
One approach to extend this to 65536 registers/constants would be to add special Move opcodes that can move to/from registers >256, by combining two of the fields to make one 16-bit address. This is the approach that Dalvik does.
You'd need a "Move from high (16-bit) to low" and a "Move from low (16-bit) to high" instruction unfortunately. I guess you could also meet in the middle and add one that splits up the 3 fields into 2 12-bit register indices (a destination and source), which would allow moving between registers two registers (0-4095) in a single instruction, as an optimization.
Similarly, the Imm instruction uses only (a, b) -- you could make (b, c) represent a single 16-bit offset into the constants table.
I guess if you really needed to index many (>65536) registers, you could fall back to indirect addressing -- like, "Move from the register indexed at this register"
The text was updated successfully, but these errors were encountered:
I've made some improvements in this area to unblock some sample code I've been looking at. 8e6d2ac relieves some of the pressure by splitting symbols (like API and field names) out from the constants table and moving script references out of the Call instruction into the constant table, 0f72e8a fixes a bug that led to high register usage in some cases, and 64cbd69 increases the field width for the Const instruction (recently renamed from Imm).
It seems unlikely so far that we will need >256 registers (and it looks like Lua has a similar maximum), but if that happens then wide Move opcode(s) plus some spill/fill logic in the register allocator is probably the next step there. There may also be ways to reduce register pressure with better codegen.
Another possibility for symbols, if we start hitting that limit again, might be to add support for naming them indirectly via a register, which could then be loaded with a wide Const instruction. Instructions using symbols would either need to be duplicated, or have an extra bit stolen from somewhere to indicate whether their operand(s) are symbols vs registers.
Each instruction is 32-bits, and has an 8-bit opcode, and 3 8-bit fields (a, b, c).
Instructions use just one of these fields to index into the registers on the stack, and the local constants table, which limits the maximum addressable registers and constants.
One approach to extend this to 65536 registers/constants would be to add special Move opcodes that can move to/from registers >256, by combining two of the fields to make one 16-bit address. This is the approach that Dalvik does.
You'd need a "Move from high (16-bit) to low" and a "Move from low (16-bit) to high" instruction unfortunately. I guess you could also meet in the middle and add one that splits up the 3 fields into 2 12-bit register indices (a destination and source), which would allow moving between registers two registers (0-4095) in a single instruction, as an optimization.
Similarly, the
Imm
instruction uses only (a, b) -- you could make (b, c) represent a single 16-bit offset into the constants table.I guess if you really needed to index many (>65536) registers, you could fall back to indirect addressing -- like, "Move from the register indexed at this register"
The text was updated successfully, but these errors were encountered: