One of the most complex parts of a Forth engine is dodoes
, i.e.,
the chunk of code executed by every word defined by a
CREATE
...DOES>
pair. The main problem here is: How to find
the Forth code to be executed, i.e. the code after the
DOES>
(the DOES-code)? There are two solutions:
In fig-Forth the code field points directly to the dodoes and the
DOES-code address is stored in the cell after the code address (i.e. at
cfa cell+
). It may seem that this solution is illegal in
the Forth-79 and all later standards, because in fig-Forth this address
lies in the body (which is illegal in these standards). However, by
making the code field larger for all words this solution becomes legal
again. We use this approach for the indirect threaded version and for
direct threading on some machines. Leaving a cell unused in most words
is a bit wasteful, but on the machines we are targeting this is hardly a
problem. The other reason for having a code field size of two cells is
to avoid having different image files for direct and indirect threaded
systems (direct threaded systems require two-cell code fields on many
machines).
The other approach is that the code field points or jumps to the cell
after DOES
. In this variant there is a jump to dodoes
at
this address (the DOES-handler). dodoes
can then get the
DOES-code address by computing the code address, i.e., the address of
the jump to dodoes, and add the length of that jump field. A variant of
this is to have a call to dodoes
after the DOES>
; then the
return address (which can be found in the return register on RISCs) is
the DOES-code address. Since the two cells available in the code field
are used up by the jump to the code address in direct threading on many
architectures, we use this approach for direct threading on these
architectures. We did not want to add another cell to the code field.
Go to the first, previous, next, last section, table of contents.