JForth 2.0 Review by Jack Woehr
Amazing Computing V4.10, 1989
[This document was scanned and converted using an OCR so any errors are the result of the conversion and not Jack's.]


"Worth the Wait"
JForth Professional 2.0

It is only fitting that the microcomputer
world's most brilliant hardware
creation, the Amiga, should be garlanded
with the most powerful software systems
available. JForth Professional from Delta
Research of San Rafael, California fulfills
this requirement from the perspective of
the professional Forth programmer.

JForth Professional is a complete
software development system centered
around a state-of-the-art, full 32-bit JSR-
threaded Forth. Forth programmers have
always been able to point to the conven-
ience of programming in Forth, but
rarely have they been able to point so
confidently to the execution speed of a
Forth system as they can now with
JForth. When JForth 1.0 was introduced
in 198(j, there was no comparable Forth
system on any popular microcomputer.
JForth set the standard, and the Forth
world raced to catch up.

JForth provides an excellent
environment for Amiga programmers,
from the rankest amateur to the profes-
sional. Forth is a compiled language with
an interpretive layer. Code may be added
to the system simply by creating a "colon
definition"--typing in the name of the
routine preceded by a colon, then listing
the "older" routines which the new
routine is to call, and terminating the
definition with a semicolon. Such
definitions may be added to the system
at any time, either by typing them in
directly or by compiling a text file.

In traditional Forth systems,
definitions are compiled into lists of
addresses of the called routines. These in
turn may consist of address lists and so
on until, at some lowest level, executable
machine code is reached. Such defini-
tions must be "interpreted" by an "inner
interpreter", a set of routines, themselves
written in Forth, which understands the
address lists.

This is not the case with JForth.
Short code routines, when referenced in
a definition, are compiled as inline code.
CThe maximum length of words to be
compiled inline is a programmer-settable
option.) References to previously defined
routines--which are called rather than
compiled inline--are laid down as
optimized JSR's or BSR's in a clever
register-addressed scheme that avoids the
use of token tables.

The entire body of a JForth JSR-
threaded definition is executable MC68k
code. Every definition ends in an RTS.
This is the fastest executing type of Forth
which can be implemented on a
traditional microprocessor. For a faster
micro Forth you would have to buy a
Harris RTX2000, a chip designed by
Forth author Charles Moore specifically
to execute Forth in silicon.

While JForth enjoys compiler
language execution speed, the program-
mer never needs to sacrifice the conven-
ience of having a fully interpretive
language at his disposal. One obvious
advantage of such a system is that you
do not have to learn about making
Amiga library calls by constant compil-
ing, loading, and crashing. You can open
windows, create graphic objects, and
move things around windows while
controlling them interpretively-without
sacrificing compiled-code speed. You
can even crash the system interpretively
a great time saver over traditional
compilers!

JForth comes on two disks. The
first disk, JForth:, includes most of the
source code in Forth for the entire
system, many utilities, and the Amiga
Include and FD files. The second disk,
the Extras: disk, contains the minimal
kernel ofJForth (neared from Assembly),
for which the source code is not
included, and two other JForth images
produced by having compiled various
assortments of the extensions and
utilities available in source on the two
disks.

The recommended precompiled
development image of JForth is about
161K. The Extras: disk also includes the
system-generating code for expanding
the kernel to a full development system
in the Sysgen drawer. The Demos drawer
contains many instructive and attractive
demos with full source. The Appls
drawer includes several intriguing and
useful applications (including a
wordcounter, a prettyprinter, and a very
dumb terminal program). The Clone
drawer contains the complete source to
CLONE. More on CLONE in a moment.

A session with JForth Professional
starts by clicking the XICON scripts on
the distribution disks. The scripts assign
logical device names to several of the
JForth drawers. JForth has a full interface
to the normal Amiga file system, and can
call up the file from which a word in the
JForth image was compiled and display
the file for the programmer. JForth
"knows" the source file locations under
these logical device names.

Double clicking on another icon
brings up JForth. System initialization
includes setting up traps in the 680x0
vector table so that programmer errors
which should incarnate the Guru, such
as odd address errors, instead evoke a
mild JForth rebuke text. Of course, if the
programmer is masochistic enough, he or
she can compile the file RUDE.F, which
generates truly shocking red-and-black
system alerts. Dictionary hashing is also
installed during JForth system initializa-
tion. The JForth Professional dictionary is
hashed for faster searches during
compiles. Compiles are now quite a bit
faster than in earlier versions of JForth.

At any time the programmer can
execute MAP, which displays a map of
the system as currently constituted. A
new image with a larger dictionary space
can be created by changing a system
variable and executing SAVE-FORTH.

For those familiar with more
common Forth systems, there are quite a
few surprises in JForth, most of them
quite pleasant. As mentioned above,
JForth definition bodies consist entirely
of executable code. A quick DUMP of
part of the dictionary is very informative
on this point. Typing DEF or SEE
<wordname> results in disassembly,
rather than decompilation. However, if
branches of the disassembled Forth word
point to other high-level words possess-
ing a name header, the name of the
word branched to is printed in parenthe-
ses next to the disassembled branch.

JForth Professional CLONE is an
optimizing target compiler. This means
that once you have perfected your
program under JForth's normal inter-
preter/compiler environment and you are
satisfied with your code, you can invoke
CLONE and produce from the compiled
program an optimized, minimally sized
target image suitable for commercial
distribution. The output of CLONE is not
a Forth system; it is your application
program pared to the bone.

JForth Professional comes with the
complete source to ODE, a congenial
and complete object-oriented extension
to JForth which allows the programmer
to explore Oops! programming style
without losing access to the underlying
simplicity of Forth syntax. ODE has early
and late binding, classes, methods and
inheritance--all the tools the OOPS
programmer has come to expect.

Among the 91 utilities in the
JForth:util drawer are: floating point
math, local variables, random numbers,
graphics code, printer logging, multi-
standard package (a useful item if you
intend to port code over from other
Forth systems), BLOCK support JForth
uses regular Amiga text files as program
source; BLOCK is a loadable option), and
a JForth implementation of the routines
contained in amiga.lib mentioned in the
Amiga manuals.

JForth Professional features
detachable precompiled modules, so you
can use certain JForth resources without
adding them permanently to the Forth
dictionary. Among the modules are a set
of Amiga Includes, an assembler and the
disassembler. Source code for the
modules and for the code to create new
modules from your own code is included
on the JForth distribution disks.

Incidentally, the disassembler is not
limited to the JForth image. Nor is the
power of words like ! (store) DUMP and
@ (fetch) limited to the JForth image. The
JForth programmer can wander around
the memory like a worm, "peeking and
poking" at will. (Watch out for collisions
with system structures!)

JForth actually has two assemblers,
one "traditional" reverse-polish Forth-
style assembler, and one featuring
Motorola forward syntax with local
labels. Use the one which suits your
needs. The Motorola syntax assembler is
especially useful in writing code words
or stand-alone routines such as interrupt
handlers. The advantage of the reverse-
polish Forth-style assembler is that one
can resort to assembler right in the
middle of a high-level Forth definition
without any "magic handwaves".

Another gratifying feature of the
JForth interpretive/compiler environment
is that JForth has F-key mapping and
command-line history and editing like
that provided by the shell. The F-keys
come pre-mapped to such useful words
as INCLUDE and MAP, but this can be
changed at any time by the programmer.
As usual, the source for these items
which comes precompiled in the recom-
mended development image is included
on the distribution disks.

JForth Professional comes with a
laser-printed manual of about 300 pages
in a three-ring binder. The various
features of the system are described in
detail. There is a tutorial for beginners in
Forth, and a glossary of the JForth
vocabulary. ODE, Amiga system calls,
and the JForth version of C structures are
all carefully documented.

JForth is the brainchild of Phil
Burk, Brian Donovan, Mike Haas and Jim
King. Phil and Mike recently used JForth
and an Amiga to win $1,000.00 and the
title of World's Fastest Programmers at
the Realtime Programming Convention
last November in Anaheim, CA.

The World's Fastest Programmer
Contest required entrants to bring their
own hardware and software and use it to
program a "Mystery Gizmo" controller to
wave a saw-blade around in the air while
a set of LED's flashed out "THE RAIN IN
SPAIN FALLS MAINLY IN THE PLAIN".
With JForth and the Amiga as their
development platform, Phil and Mike
had the one grand in the bag in a little
over an hour, while other programmers
were fuming, fussing, and burning out
the delicate stepper motors of the
Mystery Gizno.

JForth Professional is alternatively
known as JForth 2.0, the culmination of
three years of debugging, improvements,
extensions, and optimization of the
original JForth 1.0. Thereby hangs the
tale.

In 1986 when JForth 1.0 was first
announced, the ads promised, among
other things, "Optimizing Target Com-
piler" and free upgrades for the cost of
media and postage and handling. Early
purchasers eventually received the
upgrade to version 1.2, which up to now
has been the latest commercial release of
JForth. However, the optimizer was not
forthcoming, so to speak. In its place
was a Turnkey utility that stripped the
dictionary headers from the system, thus
manufacturing a legally distributable
object that did not constitute a redistribu-
tion of the underlying JForth system.

However, the object was not auto-
matically optimized, and the programmer
had to very carefully compile a minimal
image by recompiling the system
upwards from the kernel to achieve a
distributable object of reasonable size.
Furthermore, there was no way to shrink
the kernel itself, meaning that any JForth
program had a minimum size of about
70K.

CLONE, however, is the promised
goods, and does indeed produce objects
as small as about 2 1/2K. However,
much has changed with JForth other than
CLONE, and Delta Research came to
market with the greatly expanded JForth
Professional system, JForth 2.0, offering
$50.00 upgrades to registered 1.2 owners.

At this point, some of the earliest
buyers who had purchased on the basis
of the original ad (which had been long
cancelled even before version 1.2 was
available) contacted Phil Burk of Delta
Research and asked why Delta should
not keep its original commitment to a
target compiler. Phil responded by
offering a CLONE-only upgrade to
registered 1.2 owners for $10.00, which
includes the cost of media, postage and
handling. This reviewer, who has
followed and owned JForth since version
1.0, is glad to see Delta honoring its early
advertisements.

JForth has its quirks, some appar-
ently rooted in the collective personality
of the Delta team. While JForth is
advertised as "Forth 83 Standard". This is
an impossibility. The 1383 Standard
(unwisely, in many opinions) defined
Forth in terms of 16 bits. A 32-bit Forth
cannot be 83-Standard, though it may
resemble the standard quite closely from
the programmer's point of view.

Further, philosophical differences
between Delta and certain trends of the
Forth 83 Standard led to some anomalies:
NOT in JForth is a logical Boolean NOT
instead of the bitwise NOT prescribed by
the 83 Standard. Division is floored to
zero (O) in JForth, instead of towards
negative infinity, which is the 83
Standard. The familiar division operator
UM/MOD is missing and is replaced by
U/ which operates in a slightly different
manner.

Delta Research has not been alone
in its conflict with the 83 Standard. The
world's largest Forth vendor, FORTH
Inc., has never totally reconciled itself to
the 83 Standard. The question may soon
be moot. The Forth language is in ANSI
X3J14 procedure right now, and if
anything may be gleaned from the BASIS
documents leaking out from the commit-
tee, the ANSI Standard Forth to emerge
in 1990 or 13~1 will contain radical
departures from the 83 Standard, which
later was very heavily tilted towards 16-
bit micros.

In any event, the Forth standard is
currently undergoing revision at the ANSI
level to deal with the problems vendors
faced as Forth grew beyond the horizons
envisioned by the 1383 Standards
committee. As a rooter on the sidelines
of the current Standardization effort, it is
my observation that JForth substantially
conforms to the functionality of the still-
evolving ANSI Standard BASIS.

Some of the observed anomalies in
JForth are addressed by the JForth
loadable multi-standard package which
allows the programmer to go back all the
way to FIG Forth if desired, but anyone
intending on porting code from other
Forths should be aware that the old saw,
"If you've seen one Forth, you've
seen...one Forth" is not ready for
retirement quite yet.

Experienced Forth programmers
will have mixed feelings about the
absence of local multitasking in JForth.
Phil and Mike feel local multitasking is
inefficient on the Amiga; they recom-
mend using the Amiga Exec facilities for
spawning child processes. Your corre-
spondent favors the syntactic conven-
ience of Forth-style local multitasking
and hopes to prevail upon the Delta
gang to hook up all the stubs they
purposely left in the kernel for local
multitasking. Those stubs include full
implementation of local variables, and
make it possible for the programmer to
install local multitasking on his own! I
may try it Real Soon Now.

However, not one of the quirks of
JForth renders the system unusable or
even difficult to use. Forth programmers
just tend to be eccentric and opinionated
(talk to me sometime), and the Delta
gang is no exception!

Most important, I cannot envision a
more suitable environment for program-
mers unfamiliar with the Amiga system
resources to pleasantly and efficiently
explore the intricacies of the Exec-
Intuition-AmigaDOS universe. The value
of the interpretive layer, combined with
the compact syntax of Forth and the
blazing execution speed ofJForth,
should not be taken lightly by Amigans
nor professional Forth users.

Author's Info:
Jack Woehr is a Forth programmer at
Vesta Technology, Inc. in WheatRidge,
CO. He is Chapter Coordinatorfor the
Forth Interest Group, and host ofthe
Forth Conference on the WELL  in
Sausalito, CA. Mr. Woehr as also Sysop of
the RealTime Control & Forth Board,
which is part of the CFB Forth Network