On 2016-02-06 11:05:06, "Serhiy Storchaka"
On 05.02.16 23:03, Andrew Barnert via Python-ideas wrote:
But why not make it even simpler and just have all unpacked instructions be 32-bit? Sure, that means unpacked code arrays are bigger, but it's not like the optimizers are going to be looping over the same array a zillion times and worrying about cache spill (or that the optimizers will be in a hotspot in the first place). Then we've just got an int32*, and a jump to offset 76 is a jump to the 4 bytes at bytecode[76] (or, in Python, where we may still have to use a bytes object, it's at worst a jump to bytecode[76<<2]).
My idea was to not add new opcodes for unpacked form and keep unpacked form executable. Thus we have 16-bit LOAD_CONST and 32-bit LONG_LOAD_CONST, but only 16-bit POP_TOP and COMPARE_OP since POP_TOP has no argument and the argument of COMPARE_OP always fits in 8 bit. Unpacked form always uses long variant if it exists.
Alternative variant - always use 32-bit instructions and don't pack them to 8 or 16 bits. This will increase bytecode size by 4/2.73 = 1.5 times, but will make some parts of compiler, optimizer and interpreter simpler.
If, at some point, we find that 32 bits aren't enough (because we're starting to get code objects containing more than 4 million instructions), we could then add a 'wide' form with 64-bit instructions. Just a thought...