One of the more difficult issues which the committee took on
was the problem of divorcing the specification of
implementation mechanisms from the specification of the
Forth language. Three basic implementation approaches can be
quickly enumerated:
- Threaded code mechanisms.
These are the traditional approaches to implementing Forth,
but other techniques may be used.
- Subroutine threading with "macro-expansion" (code
copying). Short routines, like the code for DUP,
are copied into a definition rather than compiling a
JSR reference.
- Native coding with optimization.
This may include stack optimization (replacing such phrases
as SWAP ROT + with one or two machine
instructions, for example), parallelization (the trend in
the newer RISC chips is to have several functional subunits
which can execute in parallel), and so on.
The initial requirement (inherited from Forth 83) that
compilation addresses be compiled into the dictionary
disallowed type 2 and type 3 implementations.
Type 3 mechanisms and optimizations of type 2 implementations
were hampered by the explicit specification of immediacy or
non-immediacy of all standard words.
POSTPONE allowed
de-specification of immediacy or non-immediacy for all but a
few Forth words whose behavior must be
STATE-independent.
One type 3 implementation, Charles Moore's cmForth, has both
compiling and interpreting versions of many Forth words. At the
present, this appears to be a common approach for type 3
implementations. The committee felt that this implementation
approach must be allowed. Consequently, it is possible that
words without interpretation semantics can be found only during
compilation, and other words may exist in two versions: a
compiling version and an interpreting version. Hence the values
returned by
FIND may depend on
STATE, and
'
and
['] may be unable to find words without
interpretation semantics.