[Python-Dev] Re: new bytecode results (original) (raw)

Damien Morton newsgroups1@bitfurnace.com
Fri, 28 Feb 2003 12:34:19 -0500

> Are you suggesting a test for LOADFAST before the switch, > > e.g. > if (opcode == LOADFAST) { > // 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 COMMONOP: goto nextInstruction; case COMMONOP: ... goto nextInstruction; default: ; } switch (opcode) { case UNCOMMONOP: case UNCOMMONOP: } 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.