With a token threaded Forth, each execution token is an offset into a table of code field addresses. The inner interpreter fetches the execution token pointed to by the instruction pointer and indexes into the token table, where it fetches the code field address of the word. Parameter fields may be addressed in various ways, depending upon the details of the implementation. One approach would be to have any word needing a parameter field load its address with a load immediate instruction in a manner similar to the direct threading scheme. In this case, it is more convenient to alter the code field address of a word, and have the new code field provide a new parameter field if necessary.
The beauty of the token threaded approach is that all of the altered bindings are conveniently contained in a single table. Each task can be provided with a save buffer to hold its version of the altered token table. To perform a context switch, we can merely copy the token table off to the old task's token save buffer, and copy the new task's save buffer into the token table.
If we have access to the source code for the inner interpreter, we can even do better than that: we can have the inner interpreter find the token table by an active token table pointer. This eliminates all the copying and provides a context switch that only requires that we swap pointers to the token table rather than swap the contents of the table. On a machine with a double indexing capability, the active token table pointer can be held in an index register, thereby reducing interpretation overhead to a minimum. If double indexed indirect addressing is available, the entire inner interpreter may be reduced to a couple of instructions. If post-incrementing and chained indirection are also available, the inner interpreter might even be implemented as a single instruction.