[Python-ideas] More compact bytecode

[Andrew Barnert]

On Thursday, February 4, 2016 12:13 PM, Sven R. Kunze <srkunze at mail.de> wrote:

> On 04.02.2016 19:55, Serhiy Storchaka wrote:
>>  On 04.02.16 19:27, Sven R. Kunze wrote:
>>>  On 04.02.2016 17:55, Serhiy Storchaka wrote:
>>>>>>  1. Add 1-byte dedicated opcodes for most used opcodes with 
> arguments.
>>> 
>>>  Do you have a working CPython to showcast this?
>> 
>>  Not yet. The interpreter is easy, but the compiler is more complicated 
>>  in this case.
>> 
>>>>>>  2. Use 16-bit opcodes as in WPython.
>>> 
>>>  Same question as above + does it make sense to combine those two 
>>>  options?
>> 
>>  Of course not. Having some opcodes to be 8-bit kills the benefit of 
>>  all 16-bit opcodes.
> 
> Are you sure? I still could imagine some benefit.


The only benefits I can see for using 16-bit opcodes are:

 * You can treat the bytecode as an (unsigned short *) instead of (unsigned char *) and do 16-bit reads everywhere instead of 8-bit reads. This will no longer be true if you have to do an 8-bit read and then conditionally read more bits.

 * The ceval loop can be simplified if it doesn't have to deal with variable lengths. This will no longer be true if you have to deal with variable lengths.

So, unless you're imagining something else, I don't think there is any benefit to be gotten by directly combining the two.

You may be able to import some of the "spirit" of the first one into the second, but I'm not sure it's worth it. One of the minor problems with wordcode is that args in range [256, 65536) now take 4 bytes instead of 3. If you cram a few bits into the opcode byte, you can push the range farther back. I'm guessing it's pretty rare to do LOAD_CONST 256, but giving, say, 5 bits to JUMP_ABSOLUTE, and 2 bits to each of the various relative jumps, would cut down the need for EXTENDED_ARGS dramatically.