DOES> doesn't work

[drj11]

It's not implemented yet.

Implementation Note:

The compile time behaviour of DOES> is to compile (does>) followed by EXIT into the current word, followed by(INIT), a short primary machine code sequence that implements the initialisation time behaviour. (note that the rest of the current word will be compiled after(INIT)up to the final;.

The run time behaviour of DOES> (implemented by (does>)) is to modify the Code Field of the most recently defined word to point to (INIT) (which immediately follows (does>) in the word list).

The initialisation time behaviour (of the word defined using the defining word that contains DOES> in its source) is implemented by the (INIT) code:
it is to set CODEPOINTER to the words following (INIT) and continue in the threaded interpreter.
Thus executing the word following DOES>.

(INIT) is the same code everywhere is appears, it needs to setup CODEPOINTER to a different sequence of threaded code (each defining word will instantiate a fresh (INIT)).
This is possible because after the indirect jump THIS will point to (INIT).

The minimal (INIT) then is just a jmp to the code that actually does the work.
Intel-64 doesn't have an absolute 64-bit jump.
But it does have this:

See http://www.ragestorm.net/blogs/?p=107 for this piece of code:

jmp [rip+0]
DQ someaddr

This is handy.
It's a fixed 14 byte sequence that will jump to a fixed location.

So at compile time DOES> can copy this fixed machine code sequence after (does>).

[drj11]

does> is now implemented, but it's not particular well tested.

[drj11]

There were bugs. They've been fixed 11ae5c4