bpo-47120: define virtual opcodes in opcode.py. Better organization of jump opcodes. #32353
Conversation
… opcode.py. generate some of the utility functions from there
| virtual = {} | ||
|
|
||
| RELATIVE = 0x1 | ||
| ABSOLUTE = 0x2 |
There was a problem hiding this comment.
Aren't we about to remove all absolute jumps?
There was a problem hiding this comment.
Yes, and then this flag will not be needed.
| # (Pseudo-instructions used in the compiler, | ||
| # but turned into NOPs by the assembler) | ||
|
|
||
| def_op('SETUP_FINALLY', -1) |
There was a problem hiding this comment.
These are an internal detail of the compiler. They never exist in the final bytecode, so I don't think they should be here.
There was a problem hiding this comment.
The point was to autogenerate some of the macros around them.
There was a problem hiding this comment.
If the code to generate the macro is large than macros, that suggests to me that it isn't worth it.
There was a problem hiding this comment.
For me it's not about how long the code is, but about how many places we need to change when we add/remove/change an opcode (i.e., maintainability).
We will need to do that if we want to use the evenness of a jump opcode to determine its direction (I'm not entirely sure we want to do that though). |
|
I'll make the jumps change with the current scheme and we can refactor afterwards when the mess is more obvious. |
|
Ultimately I expect that we will want all opcodes to be auto-generated from profiling information, to reduce the effective size of the dispatch table. |
https://bugs.python.org/issue47120