The presentation from SPbPython community / PiterPy meetup about a CPython bytecode evolution. What has changed in CPython since the release of CPython 3.6. One example with EXTENDED_ARG opcode was shown.
program in the CPython interpreter - Cached in .pyc files so that executing the same file is faster the second time - Run on a VM that executes the machine code corresponding to each bytecode
return 0 print(v) foo(123) compilation 64 00 64 01 84 00 5A 00 65 00 64 02 83 01 01 00 64 03 53 00 bytecode source code 1) Parse source code into a parse tree (Parser/pgen.c) 2) Transform parse tree (CST) to an AST (Python/ast.c) 3) Transform AST into a Control Flow Graph (CFG) (Python/compile.c) 4) Emit the bytecode based on the CFG (Python/compile.c) 5) Optimize the bytecode with peephole optimizations (Python/peephole.c)
will not be added, removed, or changed between versions of Python https://docs.python.org/3/glossary.html#term-bytecode Bytecodes are not expected to work between different Python VMs, nor to be stable between Python releases
arg = 2 bytes), but opcodes < HAVE_ARGUMENT (0x5a) ignore it 0x53 RETURN_VALUE 0x65 LOAD_NAME 5 ('val') 0x05 0x00 https://bugs.python.org/msg266417 Faster (27): up to 11% faster Slower (1): the worst slowdown is only 7% Not significant (14)
opcode which has an argument too big to fit into the default two bytes. ext holds two additional bytes which, taken together with the subsequent opcode’s argument, comprise a four-byte argument, ext being the two most-significant bytes. https://bugs.python.org/issue32625