-
Notifications
You must be signed in to change notification settings - Fork 52
Open
Labels
epic-registersIdeas related to a register VMIdeas related to a register VM
Description
Using a simple notation for instruction format (python/cpython#100957, python/cpython#100895) we can describe instructions with any number of opargs:
IX
: An instruction without oparg, using two bytesIB
: An instruction with one oparg, using two bytesIBBX
: An instruction with two opargs, using four bytesIBBB
: An instruction with three opargs, using four bytesIBBBBX
: An instruction with four opargs, using six bytes- Etc.
I propose a hybrid instruction format where the first word of the instruction (opcode and oparg1) is decoded by the "infrastructure", and subsequent words (oparg2, oparg3, oparg4, etc.) are decoded by the code generated specifically for that instruction. For example, if we had a BINARY_OP_R
instruction taking 4 opargs, the opcode definition would look like
register instr(BINARY_OP_R, (left, right -- res. unused)) {
... // Implementation
}
and the generator would transform this into
TARGET(BINARY_OP_R) {
word = *next_instr++;
oparg2 = word.first_byte;
oparg3 = word.second_byte;
word = *next_instr++;
oparg4 = word.first_byte;
PyObject *left = REG(oparg1);
PyObject *right = REG(oparg2);
PyObject *res;
... // Implementation
SET_REG(oparg3, res);
DISPATCH();
}
There are complications for the 3-arg version of EXTENDED_ARG
for which I think I have a solution, see #539
brandtbucher and iritkatriel
Metadata
Metadata
Assignees
Labels
epic-registersIdeas related to a register VMIdeas related to a register VM