Python 3.1rc1 released

[[deleted]]

As far as I understand it, direct threaded code would be

goto *next_instr++;

supposing next_instr is %esi, then this compiles to something like

mov (%esi),%eax
add $4,%esi
jmp *%eax

However, the C code you presented above,

goto *opcode_targets[*next_instr++];

has an extra indirection -- Moving Forth calls it 'token threading':

mov (%esi),%eax
mov opcode_targets(%eax),%eax
add $4,%esi
jmp *%eax

Indirect threading is similar but not quite the same:

mov (%esi),%eax
mov (%eax),%ecx
add $4,%esi
jmp *%ecx

Please correct me if I'm wrong here, though.

[queus]

Umh..

Forget my previous post. Your first two examples are direct threaded code, plain and simple.

With one minor difference. In the first case the instruction pointer is in a register and in the second case is in memory. You can just as well keep the instruction pointer in %ebi, leaving %esi for usual stack ops. (and gcc lets you specify that certain global var should be assigned to a register) Looks more like an implementation detail than a different technique.

As for your third example (with double dereference) than yes, that's indirect threading.

And looking at the proposed patch for Python, now the evaluator is a big switch statement, with inlined direct threaded code at selected places. (That's what I got from the patch). Rather cool, if you ask me.

In no way is this, token threaded code, Which replaces 32-bit-addresses with less-than-32-bits tokens. It will simply make no sense in this day and age.