All DatabasesMacTech Vol 03-1987
Upgrades
Volume Number: 3
Issue Number: 4
Column Tag: Forth Forum
New Upgrades for MacForth & Mach2
By Jörg Langowski, MacTutor Editorial Board, Grenoble, France
MacForth Plus and Mach 2.1
This month I'd like to give you an overview of the most recent versions of the two
Forth implementations for the Macintosh that you've been reading about most in this
column. That is, Mach2 (version 2.1) and MacForth (Plus). NEON, making up a
category on its own, I'll leave out this time.
Regular readers of this column will have noticed that the majority of Forth
examples have been written in Mach2. This shouldn't be meant as a bias towards that
particular system, only that I think it is better to stay consistent and use one
implementation, pointing out differences to other Forths if they arise.
Let's start with a short description of MacForth Plus. Since it is a major change
compared to the older versions, it helps to print some excerpts of the release notes by
Creative Solutions included with the system.
"MacFORTH Plus has been completely rewritten from scratch...Most notably, in
order to support multi-tasking the file system has changed dramatically. Other
changes have been made to make MacFORTH Plus run much faster, for instance with an
entirely new method for doing loops. The old system of using the 68000 Trap
instruction and F-line traps for defining words has been abandoned in favor of a
system that will work with the 68020 and the 68881 floating point coprocessor. This
new arrangement is also much faster, but is not nearly as compact as the old system.
Thus, the kernel is quite a bit larger.
You will still be able to write applications that will run on 128K machines, but
it is presumed that for your development environment you use at least a 512K
machine.
While block files are still fully supported, MacFORTH Plus also provides the
ability to write programs in ordinary text files and provides an editor as well. Proper
use of the editor could change your programming environment completely, as you can
execute a selection range by hitting the Enter key. Output will be directed into the file
itself. [looks very similar to the MPW environment in that aspect - JL]. This means
you can easily accumulate a lot of information in the file (e.g., by executing WORDS)
and read it at your leisure. If you do all your work in this way you'll also have a log
file recording exactly what you did.
If you use the system window to input commands, there's a command line editor.
It saves the last four commands you typed and can be invoked at any time to allow you to
edit or re-use them.
Errors are reported by alert boxes in true Macintosh style.
You can enable and disable the programmer's switch with EnableSwitch and
DisableSwitch. This cannot be guaranteed to work on all future Macintosh products,
however.
MacFORTH Plus does multi-tasking.
A nearly complete set of words is provided for running alerts, modal dialogs, and
modeless dialogs.
Words to use resource templates in defining menus, menubars, controls, and
windows have been added for those who prefer this method.
The way DO ... LOOP works internally has been changed dramatically. It's twice as
fast as it used to be. There is some cost for the additional speed, however. First and
most important, I is no longer the same as R@. You should not use I or any of its
relatives (like IC@, I+, J, etc.) unless you are referring to a loop index. The loop
index is no longer kept on the return stack, but is now in a register.
Some people will have some rewriting to do to get their old code to work because
of this. You must be sure you have used I and R@ correctly...Second, since the new
loops use registers D4, D5, and D6, these are no longer available for your own use.
And finally, the new loop system works somewhat differently in extreme
cases...This is because the new system checks for the index crossing the limit rather
than checking how the index is related to the limit. (This is actually the method
recommended in the Forth 83 standard.)
In order to properly support the multi-tasking, it was necessary to drop the old
FCB system and install a file interface like the Pascal interface.
There are also 3 new variables for I/O redirection: INFILE, OUTFILE, and
DEBUGFILE. Input is taken from INFILE; most output goes to OUTFILE, except error
reports, which go to DEBUGFILE. Any of these may be a file, a MacForth wptr, or a
device driver.
Code fields are now 4 bytes long instead of 2. Register allocation has completely
changed. Vocabularies are set up differently, as is the token table (tokens now 6 bytes
each). The OBJ resource now includes both the old object and the token table (so ROOM
will report much larger values -- it includes the token table). Most of these changes
will impact only very advanced users.
One new feature, contributed by John Baxter, provides for a "Tools" Menu.
Program development tools can reserve space on and use this common menu rather
than allocating a new menu for each tool. This has already proven to be almost
indispensible with the expanding number of advanced tools being uploaded to
Compuserve, and available through the MacForth User's Group.
Another feature, provided by Tim Hewitt, and now included in the default
snapshot token, includes any TEXT files that were double-clicked on the Finder
desktop, if the Option key is held down when the files are launched. This is
particularly useful for turnkey scripts,.... Macintalk support is included.
Calling procedures and functions written in other Languages:
This effort is currently in process, (examples are working fine), but we are not
sure about the format we should use for the interface (Linking templates, etc.), and we
would like to know what formats end-users would like to see (eg. MDS or MPW?).
We'll upload the results to Compuserve when ready.
So much for the new features of MacForth Plus as described by CSI. Let's now
proceed by a more detailed comparison of the two Forth systems.
Speed
Execution speed is not everything, but it matters a lot. Less if you use a lot of
toolbox calls; more if you need to write time-critical code, as for instrument control,
or in heavy number-crunching.
Listing 1 shows some benchmarks that I used on the two Forth systems: a routine
that inverts the screen 50 times, the well-known Sieve of Erastothenes, one million
empty DO...LOOPs, and a speed test of the floating point implementation. The words
counter and timer are not implemented in MacForth and are therefore redefined here.
The figures - given in Table 1 - immediately show that MacForth Plus is a great
leap forward compared to the MacForth K2.4 version. Mach2, however, since it offers
the distinct advantage of generating 68000 code directly instead of going through an
'inner interpreter' as many other Forths, still executes twice as fast (on the average)
as MacForth Plus.
The discrepancy between the two systems is evident for the floating point
benchmark, with Mach2 executing SANE routines 5-10 times faster than MacForth. It
is not clear to me why the floating point routines under MacForth should generate so
much overhead in an empty loop, but the fact remains. The MacForth floating point
words themselves (after subtracting the loop overhead) execute not too much slower
than the Mach2 versions; still, there is a constant difference of approx. 250 µs per
floating point operator.
The advantage of the MacForth floating point system is that rounding and
exception trapping are under very good control from your program. In this aspect,
Mach2 does not implement the full SANE package.
For faster numerics, there exists a good 32-bit floating point package for
MacForth in the public domain (Compuserve or MacForth Users' Group); for Mach2,
see my columns in MT V2#7 and V2#8 for 32-bit floating point routines.
It is not only execution speed that matters but also loading speed. Both systems
are very fast in loading long files. Although I don't have one long program that will load
on both systems, I tested Mach2 and MacForth Plus with several files of comparable
length and got an average loading speed of about 1.5 Kbyte/sec for Mach2 and 0.8
Kbyte/sec for MacForth Plus (both from an SCSI hard disk). Mach2.1 seems to have
the edge here because of its new hash-coded vocabulary structure; switching off
hashing lets Mach2 load at the same speed as MacForth Plus.
Debuggers
MacForth has had a built-in debugger from the very start, and, of course,
MacForth Plus has kept it. Its TRACE option will insert a trace token before each
compiled word, so that on execution (with the DEBUG feature on) the name of the word
executed will be printed together with the current stack picture. DEBUG output can be
redirected to a debug file [this is new], in order to leave the screen output
undisturbed.
The stack picture that is displayed with each word helps a great deal in analyzing
algorithms that do a lot of stack manipulation; one can see very quickly whether a
routine left something on the stack that wasn't supposed to be there, or whether an odd
address is generated by some bug, etc.
The MacForth debugger does not really decompile the code since you have to
execute it to get it displayed. For decompilation, however, there exist a number of good
tools in the public domain. A Forth decompiler included with the system would be nice,
though, e specially since the structure of MacForth Plus definitions has changed a lot
from the older MacForth versions.
Debugging under Mach2 is different, due to the different implementation that
directly generates machine code. Therefore, the debugger (included in the v2.1
release) resembles Macsbug a lot. You can enter the debugger by selecting a menu
option or executing DEBUG. This will give you a Macsbug-like window that accepts
Macsbug-like commands. In addition, you can refer to Forth words by their names
within the debugger, and when code is disassembled, the debugger displays the names of
Forth words corresponding to the code. JSR-threaded words are decompiled without
problems this way; if inline code has been included using the MACH option, only the
most standard definitions like swap, drop, literals etc. are recognized.
Tracing code under Mach2 is more cumbersome than under MacForth; you have to
set machine-level breakpoints (DEBUG sets a breakpoint at the beginning of
the definition of ) and then step through the code. Evidently, it is not so easy to
monitor the stack as with MacForth - the debugger displays no stack pictures.
The interrupt switch for entering the debugger did not work in my version of
Mach2.1, and Palo Alto Shipping is working on it; they promised to have it fully
functional Real Soon Now (to steal an expression from one of my more famous
colleagues).
My preferred mode of operation is to debug Mach2 code with TMON. Forth words
are not displayed by name there, true; but all the other tools are just so much more
powerful.
For testing out algorithms, I prefer MacForth with its stack display on each step
while tracing code. You see immediately where you've been stupid in your coding.
Conclusion here: it's really best to have Mach2 and MacForth ready for debugging
a bigger Forth project.
Assemblers
Both MacForth Plus and Mach2 include an assembler. While MacForth Plus uses
the Forth philosophy of writing assembly code in reverse Polish notation, Mach2
conforms to the standard Motorola syntax.
I suppose one can get used to both assemblers. The reason why I am using the
Mach2 assembler in my examples is very simple; I still retain hopes that someone
from the non-Forth speaking community might find at least some of the assembly
language stuff interesting (and that way gain interest in using Forth as well).
Seriously, it becomes much easier to transfer code between different programming
environments if at least for assembly language, one sticks to the standard Motorola
syntax.
The 'forthy' MacForth assembler has the advantage of having a set of control
structures like if, else, then, begin, while, repeat, etc. built in. That, again, makes
machine code more readable, but raises problems when one deliberately wants to
create tight 'spaghetti' code (yuck). This is often necessary to squeeze the last bit of
performance out of a piece of code, and one can generate such 'unstructured' code in
MacForth by playing some tricks that are explained in the manual, but the result will
be even less readable than in standard assembler using labels.
Summary: if your program includes large pieces of assembly code, I suggest
using Mach2, e specially if you've been using 68000 assembly in other environments.
For small machine code insertions, both systems are probably equivalent.
Local variables and other data structures
A great deal of time-consuming and bug-breeding stack manipulation can be
avoided by using local variables and named stack parameters in Forth words.
Both Mach2 and MacForth offer these options. The syntax is not too different
between the two systems. In Mach, the word name (after the colon) is followed by a
parameter list enclosed in braces with a vertical bar separating the stack input
parameters from the local variables:
: test { a b c | loc1 loc2 loc3 -- comment } ;
while in MacForth the same is accomplished by
: test 0 1 2 locals| loc3 loc2 loc1 c b a | ;
initializing loc1, loc2 and loc3 to 0, 1 and 2 at the same time. This syntax can be
emulated in Mach2 by writing
: test 0 1 2 { a b c loc1 loc2 loc3 } ;
which makes the two approaches look very similar.
Local variables (including stack parameters) are limited to a maximum of 10 in
MacForth Plus, while apparently no restriction exists in Mach2. In the latter case, a
stack frame is generated on a local variable stack (A2) that holds four bytes for each
variable.
Calling the name of a local variable puts its value on the stack; n -> loc1
(Mach2) or n to loc1 (MacForth) stores n into the local. Sometimes it becomes
necessary to pass the address of a local variable to a toolbox routine; in MacForth this
is accomplished by writing addr.of loc1, and in Mach2 by ^ loc1.
MacForth also includes words for one- and two-dimensional array definitions and
for data structures. These definitions are left as an exercise to the user in Mach2. See
MT V2#9 on an alternate way of defining structures both in MacForth and Mach2.
Toolbox interface
The different philosophy of the implementers of MacForth Plus and Mach2 shows
up very clearly in the way the Macintosh user interface is handled. While in both
systems the most frequent elements of the user interface ( windows, menus, controls)
are supported by high-level Forth words, MacForth offers in addition, words for
handling dialogs, alerts, text edit, events, scrap and the drawing routines. This is again
consistent with the philosophy of keeping the syntax as Forth-like as possible, and
sometimes makes the code more readable. However, it can create problems when
transporting algorithms from other programs written in C or Pascal, where the
toolbox routines are called more or less according to the Inside Macintosh standard.
Mach2, in addition to supporting windows, menus and controls from within Forth
(and linking these structures to the multi-tasking environment), gives a very simple
way to directly call toolbox routines Inside Macintosh style. This is done by writing
CALL
with the appropriate number of parameters on the data (A6) stack. Mach2 contains a
table of all toolbox routines and most of the package calls together with information on
how many parameters in which format are expected on the stack. The compiler
automatically inserts glue code to take the parameters off the A6 stack (each one
occupying 4 bytes here) and pushing them on the A7 stack in the correct format.
For toolbox calls not contained in the list (there are not many), or for calling an
operating system routine asynchronously, one has to write a little piece of assembly
code to transfer the parameters correctly. Examples of this can be found in almost any
previous Forth column that deals with Mach2.
The difference is clear: toolbox calling very 'close to the machine' in Mach2,
higher level Forth-style toolbox support in MacForth. Otherwise the two systems are
equivalent, and it is again a matter of preference which one to use. For machine-level
debugging, the subroutine-threaded approach of Mach2 is easier; on the other hand,
with MacForth it might be easier to transport code to other window-oriented
Referenced by (25):