> Fundamentally, in threaded code, the execution tokens are the addresses
> of the interpretive routines [...]
> So the core of the interpreter dispatch loop becomes trivial -- and
> very fast.

The crux of threaded code is that the interpreter loop goes away
entirely.  Each "opcode" ends by dispatching to the next opcode, so
there is no return to a central loop -- e.g:

	#define DISPATCH() { \
	  register void *nextOp= (void *)fetchWord(); \
	  goto *nextOp; \
	}

	pushReceiver:
	  internalPush(receiver);
	  DISPATCH();

	pushTrue:
	  internalPush(trueObj);
	  DISPATCH();

	pushFalse:
	  internalPush(falseObj);
	  DISPATCH();

and so on.  (The addresses of the labels are the "opcodes" used to
represent a program.)

The word "threaded" comes from an analogy with sewing: execution flows
through the opcode implementations, like a needle pulling thread.
There is a truly excellent short article that I highly recommend to
the archaeologists amongst us:

        James R.\@ Bell,
        Threaded Code,
        Communications of the ACM, 16(6):370--372, 1973.

Ian