FAST Forth Native-Language Embedded Computers

David M. Sanders
San Francisco, California
I. Introduction
Many existing Forth compilers generate the code within
a compiled word in the form of a sequence of pointers to
other words. An "inner" interpreter then fetches these
pointers, one at a time, and executes the appropriate
routines that, when taken together, simulate the action of
the Forth machine model. However, an increasing number
of Forth implementations generate machine code directly
during the compilation of Forth words. While the resulting
code tends to take more space, it executes considerably
faster. There is no coded "inner interpreter" in this type of
Forth implementation; the inner interpreter is the processor's
silicon-encoded, instruction-fetching mechanism.
This article discusses certain optimization techniques
for machine code generated by a Forth compiler. The Intel
386 processor is used to illustrate the techniques, but many
of them are applicable to a wide variety of processors,
including the Motorola 68000 family. The discussion and
examples are based upon 386 assembly language1; in
practice, the optimizations would probably be carried out
directly upon machine-code instruction codes, without
CCLocal optimizations" that
are particularly applicable to
Forth compilers can greatly
reduce the amount of
machine code generated.
the use of an assembler.
In this article, I focus principally on techniques that are
particularly applicable to Forth compilers, rather than on
techniques that are common to compilers in general. The
techniques dscussed relate to certain "local" optimizations
that, when employed together, can significantly reduce the
amount of machine code that would otherwise be generated.
In particular, I look at optimizations related to three areas:
1. optimizations related to buffering the top of the data
stack in registers;
2. optimizations related to updating the data-stack pointer;
and
3. optimizations related to combining generated code
instruction sequences into shorter and faster code
instructions.
I also look into some ramifications for Forth itself, in the
form of some extensions.
II. Buffering the Stack Top in Registers
The 386 has a subroutine stack, which would be used
by Forth as the return stack. When a machine-codecompiled
Forth word calls another compiled word, an
assembly-language CALL instruction is generated; the
compilation of an exit from a Forth word would generate
an assembly-language RET.
The 386 has no explicit stacks aside from the subroutine
stack; the Forth data stack would need to be implemented
by using a register such as ED1 as the stack-pointer
register, and incrementing and/or decrementing the pointer
register as ne~essary.~
Ideally, the topmost part of the data stack should be
buffered in one or more registers, so that the number of
memory operations needed to manipulate the stack can be
reduced. The number of memory operations can be further
reduced if a variable number of items from the top of the
I data stack can be buffered in registers. Such a reduction in
I -
the number of generated memory accesses comes at the
expense of compiler complexity. In this case, the stack-
pointer register (ED1 is used in the examples in this article)
points to the top of the in-memory portion of the data stack.
During compilation, the compiler must itself keep track
of the stack "state," which is used to indicate the registers
that currently contain items from the top of the data stack.
F~~ the 386, the ideal registers to use for that purpose are
1 For those of you not familiar with lntel assembler notation, the destination
o~erand comes before the source operand. For example:
MOV EDX, EAX
This instruction sets EDX (the destinat~on) to the contents of €AX (the source). On the lntel 8088, which was used in early IBM PC's, a significant speed-up
In addition, when a register is used as a base or index register, the register in instructionexecution timecould often be realized by using string instructions
name is enclosed in square brackets [I. As an additional example:
such as STOS, even without the REP instruction prefix, whenever possible.
MOV [ED1]+4. EAX
However, in designing the 386, lntel deliberately optimized instructions such
This instruction sets the memory location addressed by [contents of ED1 plus as MOV [EDI], EAX so thatany speed-up resulting from using string instructions
four] to the contents of EAX. Most instructions permit a memory location to be without the REP prefix is completely negated, even if the pointer register (EDI)
used as either a destination or a source.
must be incremented or decremented in a separate instruction.
Forth Dimensions 33 March 1994 April