V4N4 - Complang

ROMable FORTH with Separate Headers
Robert H. Hertel
Robert D. Villwock
Microsys terns, Inc.
Traditional implementations of
FORTH assume a single computer en-
vironment in which the program is
compiled, tested and used. In this en-
vironment it is expected that:
Memory is all-RAM
Terminal and disk are available
System software (compiler,
editor, etc.) is needed
In a typical dedicated micropro-
cessor application such as a "smart"
product of some kind, there are two
distinct environments which we will
call the development and target envir-
onments. The development environ-
ment is usually the same as the
traditional FORTH environment, but
the target environment is different:
ROMlRAM memory organiza-
tion
No conventional terminal or disk
System software is not needed.
In our own work, the development
setup consists of a microprocessor
development system connected to a
prototype target system by means of
an in-circuit emulator. The memory
space can be mapped so that some
parts of the memory reside in the
development system and other parts in
the target hardware.
Until recently, the usual method of
developing FORTH software for
dedicated applications has been to
compile and test with a traditional
FORTH implementation. After testing
is completed in this mode, a "target
compiler" or cross compiler is used to
reprocess the source code to produce
the final target code. This produces
headerless target code without the
name fields and without unneeded
system software. ROM copies of this
code can be installed in the target
system.
The cross-compilation method of
producing ROMable code has several
drawbacks. Obviously it adds an extra
step to the software development pro-
cess. The cross compiler itself is com-
plex and much more difficult to use
than an ordinary compiler. With the
target names discarded, interactive
testing becomes difficult or impossible
at a critical point in the development
process.
When we selected FORTH as our
primary software development tool,
we decided to develop a new compiler
to recognize and fully support the dual
developmentltarget environments. In
the resulting implementation (called
proFORTH'") the ROMlRAM and
systemltarget separations are made as
the code is compiled. Target names
are retained in the system area of
memory in such a way that interactive
testing can continue until and even
after the target code is transferred to
ROM. When development is com-
pleted it is only necessary to program
ROMs for the appropriate memory
areas; system code is simply dis-
carded.
The remainder of this discussion
will describe those elements of the
proFORTH'" system related to com-
piling ROMable target code, and will
explain how the programmer uses the
system.
Memory Organization
The processor's memory space is
divided into three kinds of segments:
ROM -target code or read-only
memory
RAM - target variables or
readlwrite memory
DICTIONARY - system code,
names, etc. (also readlwrite)
Any number of segments of each
kind may be defined. ROM and RAM
segments are dictated by the needs of
the application and the design of
its hardware. For example, separate
ROM segments might be assigned for
an interrupt vector jump table, op-
tional code, and for all other target
code. RAM areas might be set up for
a CRT refresh memory and for all
other target RAM. Figure 1 shows a
memory map with these ROM and
RAM segments defined.
FORTH Dimensions 9
0000
lFEO
2000
4000
4800
6000
6400
7000
8000
FFFF
I
ROM 1 1
I
ROU 2 f
ROU 3 I
mmmmi
/I/////////// I
///////////// I
I
I
I
DICTIONARY I
I
0 I
I
I
I
I
I
FIGURE 1 - SAMPLE MEMORY MAP
Often a single dictionary area will
suffice, but proFORTH'" supports
multiple dictionaries and they can be
used in a variety of ways. For now we
will assume that only one dictionary
is needed.
Segments within each class are
numbered as indicated in Figure 1.
ROM and RAM numbers begin with
1; dictionaries are numbered from
zero. They are established using the
words ROM, RAM and DICTIONARY. Thus
the directives
8000 FFFF 0 DICTIONARY
6000 63FF 2 RAM
4000 47FF 3 ROM
assign the address space 8000 through
FFFF to dictionary 0, 6000 through
63FF to RAM segment 2 and 4000 to
47FF to ROM segment 3 (we will
assume throughout this article that
numbers are expressed in hex-
adecimal). More specifically, each
memory segment has a segment con-
trol block structure like the one for
Continued on next page
Volume IV, No. 4