FAST Forth Native-Language Embedded Computers

However, FastForth's EXPECT is vectored, so program-
mer utilities such as the assembler and editor may include
a more extensive line editor capability. This allows exten-
sive line editing on the target hardware during develop-
ment without sacrificing nucleus size. The line editor is
removed before the program is committed to ROM.
The line editor uses a number of variables to track the
size of the line being edited, the location of the cursor, and
other characteristics. These are annotated in detail in the
source code and in the glossary.
A headerless string array is defined for the history
capability. This array stores each string in the history in the
traditional Forth count-and-string format. The starting
address of each entry is stored in another array, STRARRAY.
This is an array of pointers. A variable, NXTLN, points to
the current string indirectly by pointing to the string array.
This means that moving from each entry to the next
consists of incrementing or decrementing NXTLN by the
size of a pointer, and handling wrap-around correctly.
The traditional Forth array was not used here because
of speed considerations. This would have been defined
something like this:
: ARRAY CREATE STRINGS * ALLOT
\ count --- I build array
DOES> >R STRINGS * R> + ;
\ entry# --- addr I
This means that every access to the array would have
involved a multiply. The double-indirection method elimi-
nates this time-consuming operation. Furthermore, using
the double-indirection method means that calculations are
performed only at the time a new line is selected, never at
access time.
Using these variables and indirection, strings are loaded
into the string array and copied from it to the edit buffer
by always referring to the variable.
A design decision was made that, when a line is copied
from the history buffer, the cursor will appear on the left
end of the line. This is due to experience with Forth. Often
a line must be edited and re-executed because a vocabu-
lary or other modifier was not given. These modifiers
typically must be at the beginning of the line, not the right-
hand end. Also, the Home key provides a quick method
for the user to move to the right-hand end of the line,
should he wish to.
The Implementation
The glossary indicates the function of each word. The
listing should be read along with the coding descriptions
of the words given below.
The implementation starts with a loader screen, screen
501. For development purposes, the debugger can be
called. For inclusion in the utilities, this call to the
debugger is commented out.
The word TASK is used as a marker in the dictionary.
During development, this is forgotten and recompiled
below the application to allow the programmer to re-
compile the application by entering the phrase RETRY
Forth Dimensions
TASK. Once an application is deemed complete and is to
be added to the utilities, TASK is forgotten, the application
is compiled, then TASK is redefined on top. Used in this
manner, the word acts as a moveable marker to indicate
where the utilities end and applications begin.
The word BELL defines a word which emits an ASCII
bell character. This is typically used as an alarm or an alert
on some error.
Line five of screen 501 forces the line input code to be
(EXPECT) , the nucleus input working word. This is done
at compile time to ensure (especially during debugging)
that, in the event of a compile-time error, EXPECT will
have a valid working word to execute.
On line seven, we establish the vocabulary where most
of the line editor will reside. This hides the bones of the
application from the user once the project is completed.
Line nine of screen 501 effects compilation of the next
six screens. It is written this way because the word +BLK
and its family may not exist when this code is compiled
into the utilities.
Screen 502 compiles a number of variables and constants.
These are described in the glossary. The most
important one to the user is the constant STRINGS, on line
seven. It indicates the number of strings to be preserved
in the string array. It is the equivalent of the Unix
environment variable HI STORY. In order to effect changes
in this constant, the line editor must be recompiled.
On line 11, a most implementation-specific constant
sets the maximum line length. This constant should
specify the maximum line length that the user may enter
into the terminal input buffer in the course of normal Forth
operations.
The next screen, 503, shows the construction of the
string array by the word MAKESTRS. This word allots
memory for each string in the buffer, and stores its address
in the array of string addresses, STRARRAY. This word is
executed once, at compile time.
The next two words handle the process of moving from
one entry in the string array to the next. UP moves from
a given string to the next higher address string, and
handles wrap-around at the top. DN defines the process for
moving down in the suing buffer. These two words turn
the string array into a ring buffer for strings.
The phrase NXTLN F@ F@ will show up often in the
remainder of the code, as that phrase always returns the
address of the current string buffer entry. In a traditional
Forth, this phrase would probably be built into a word to
make the code more readable. However, the FastForth
optimizing compiler turns this three-word phrase into two
processor instructions. The implementor chose to go for
faster code over programming elegance.
Similar phrases based on variables, such as CURS F@
and SIZE F@, resolve to one processor instruction, and so
are not built into words that make pseudo-constants.
HISTORY, and its alias HI ST, at the top of screen 504,
show the ring string buffer at work. They exist to allow the
user to view the contents of the string array. They are made
generally available to the user by placing them in the FORTH
vocabulary. HISTORY walks through the ring buffer, dis-
11 March 1994 April