Ken Jin <kenjin4...@gmail.com> added the comment:
Thanks Martmists for the bug report, I'll try to address some of your concerns: > The reason for this seems to be the lack of definition in `opcode.py` aside > from being mentioned in _specialized_instructions. If I understood Mark's intentions in PEP 659 correctly, when you call dis.dis on any normally generated code object, specialized instructions will never show up. Specialized instructions are a hidden implementation detail, and instead the normal generic instruction will appear. So there isn't really a need to support it (any Python hand-crafted specialized instruction will likely segfault anyways). > Additionally, it seems dis._unpack_opargs is not yet prepared to support > opcodes like LOAD_FAST__LOAD_FAST which take two arguments Sorry, I don't quite understand what you mean here. The superinstructions do not use different bytecode format: ie they take only one oparg. LOAD_FAST__LOAD_FAST works by reading the *next* instruction's oparg. So: LOAD_FAST 0 LOAD_FAST 1 LOAD_CONST 0 Becomes: LOAD_FAST__LOAD_FAST 0 LOAD_FAST 1 LOAD_CONST 0 LOAD_FAST__LOAD_FAST will increment program counter inline [1] to read the oparg of the instruction after it without going through eval loop, then on dispatch it will effectively "skip" the next instruction and go straight to LOAD_CONST. The speedup comes from skipping eval-loop and dispatch overhead of one instruction. The bytecode format is unchanged. [1] https://github.com/python/cpython/blob/07cf10bafc8f6e1fcc82c10d97d3452325fc7c04/Python/ceval.c#L1755 I hope this helps you. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45362> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
