[Python-Dev] Re: new bytecode results

[Damien Morton]

> > Are you suggesting a test for LOAD_FAST before the switch,
> >
> > e.g.
> > if (opcode == LOAD_FAST) {
> >  // load fast
> > }
> > else switch (opcode) {
> >  // body
> > }
>
> Yes.


Hmm, I might even be able to do something like this:

if (opcode >= LOAD_FAST_0) {
    oparg = opcode - LOAD_FAST_0;
    ...
    }
else switch (opcode) {
}


> Yes, except that in the default case the code is placed after the
> first switch.
>
> switch (opcode) {
>   case COMMON_OP:
>     goto nextInstruction;
>   case COMMON_OP:
>   ...
>     goto nextInstruction;
>   default:
>     ;
> }
>
> switch (opcode) {
>   case UNCOMMON_OP:
>   case UNCOMMON_OP:
> }
> goto nextInstruction;


Why would you do it as two consecutive switches, rather than two nested
switches? The current ceval code has nested switches for when CASE_TOO_BIG
is defined.


Hmmm.

I would guess that the handling of default within a switch is probably
highly optimised by the compiler, using if/then range tests. If we
structured the opcodes so that uncommon ops were a two-byte opcode, we could
do something like this:

switch (opcode) {
    default:
        load_fast(opcode - LOAD_FAST_0);
        goto nextInstruction;
    case COMMON_OP1:
        ...
        goto nextInstruction;
    case COMMON_OP2:
        ...
        goto nextInstruction;
    case UNCOMMON_OP:
        break;
}

opcode = NEXTBYTE();
switch(opcode) {
    case UNCOMMON_OP1:
        ...
        break;
    case UNCOMMON_OP2:
        ...
        break;
}

This would free up the opcode numeric space for fast/frequent ops with
immediate args encoded into them.