Go to the first, previous, next, last section, table of contents.


DOES>

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.