These words provide access to code addresses and other threading stuff in Gforth (and, possibly, other interpretive Forths). It more or less abstracts away the differences between direct and indirect threading (and, for direct threading, the machine dependences). However, at present this wordset is still inclomplete. It is also pretty low-level; some day it will hopefully be made unnecessary by an internals words set that abstracts implementation details away completely.
>code-address
xt -- c-addr gforth "to-code-address"
c_addr is the code address of the word xt
>does-code
xt -- a-addr gforth "to-does-code"
If xt ist the execution token of a defining-word-defined word, a_addr is the start of the Forth code after the DOES>; Otherwise a_addr is 0.
code-address!
c-addr xt -- gforth "code-address-store"
Creates a code field with code address c_addr at xt
does-code!
a-addr xt -- gforth "does-code-store"
creates a code field at xt for a defining-word-defined word; a_addr is the start of the Forth code after DOES>
does-handler!
a-addr -- gforth "does-handler-store"
creates a DOES>-handler at address a_addr. a_addr usually points just behind a DOES>.
/does-handler
-- n gforth "slash-does-handler"
the size of a does-handler (includes possible padding)
The code addresses produced by various defining words are produced by the following words:
docol:
-- addr gforth "docol:"
the code address of a colon definition
docon:
-- addr gforth "docon:"
the code address of a CONSTANT
dovar:
-- addr gforth "dovar:"
the code address of a CREATE
d word
douser:
-- addr gforth "douser:"
the code address of a USER
variable
dodefer:
-- addr gforth "dodefer:"
the code address of a defer
ed word
dofield:
-- addr gforth "dofield:"
the code address of a field
You can recognize words defined by a CREATE
...DOES>
word
with >DOES-CODE
. If the word was defined in that way, the value
returned is different from 0 and identifies the DOES>
used by the
defining word.