The implementation technique of keeping on rewriting the Forth into
assembler until all the Forth words in the pool of words to be defined
have been finished is interesting ... one imagines that if you were
targeting an assembler available for a range of processors, such as
gas or tasm, you could have an eForth-style implementation in a single
file, mixing code words and colon definitions, and then process it
into a file ready for assembly.
The automatic processing also eliminates the need for macros in the
assembly language file, making it more likely that something could be
made that is flexible as to target assembler.
Indeed, given a system as small as a BusyBox floppy disk, which has
awk, and an awk script that can assemble based on a table used in a
table assembler like tasm, you could bootstrap a first minimal-kernal
Forth with awk and the correct assembler table. Of course, the
difference between bootstrapping and cross-compiling would be
switching assembler tables: if not bootstrapping, you can use
whichever cross-assembler desired.
Since the author's purpose was to write programs in a HLL and Forth
was picked because implementing a small-C seemed to be too demanding,
he ran into mode-switch problems - all his immediates are intrinsics
and immediates are limited to intrinsics. But a script targeted to
writing an assembly language Forth system could avoid that, since once
the assembly implementation file is written, the directives to the
file writer are no longer needed. So a small collection of compiler
directives, a #: word to define extensions, and both the built-ins and
extensions named as [[word]] to stand out when they are used in the
definition file.