This is not the place to go into how Forth works (see PCW Dec 1981 or Brodie's magnificent book Starting Forth). Nor am I going to oversell Forth as the universal panacea for programming problems as has, unfortunately, been done so often before.

After a year of working in Forth I have formed a somewhat more realistic opinion of its capabilities and shortcomings; suffice it to say that I remain impressed enough to use it whenever appropriate for serious programming tasks and to offer these Benchmarks for evaluating Forth systems.

Forth is definitely not a suitable replacement for Basic as a beginner's language, anymore than an AC Cobra is a suitable car for learner drivers. Logo is a much better bet to take on this role. What Forth does offer, as a second language, is a complete programming environment which offers more control over the computer than any other interactive system which is currently available. Notice the word interactive: the main rival to Forth for flexibility and power in systems programming is C (and its progenitor BCPL). C offers advantages over Forth in that it produces stand-alone machine code modules which can be linked to programs produced by other compilers, whereas Forth generally requires run time support from a Forth interpreter. C-produced code will usually run slightly faster, too. But C is not interactive; it is a compiler in the old Fortran tradition (and even slower to compile) and thus goes against the grain of the microcomputer philosophy. For large projects by professional programmers this doesn't matter, but for we mortals the interactive 'suck-it-and-see' approach is what makes programming bearable.

Forth is not only interactive; it is more interactive than any other language in existence. How else can you sit at a terminal and work in any number base you desire at a keystroke, dump blocks of memory, mix Assembler in with your high level code, manipulate any object from a bit up to an array or file without ever leaving the system? And it's structured, too. One myth which circulates about Forth is that the code is always unreadable; the truth is that it can be as readable as you want to make it. The commenting facilities in Forth are unlimited and since you decide word names (up to 31 characters on my system) it is your responsibility to make them intelligible. One day soon I intend to publish in PCW a fairly heavyweight piece of Forth code I have produced which is certainly as readable as Pascal.

Anyway, on to the Benchmarks. Since Forth is an extensible language it presents some problems in choosing the level at which to write Benchmark programs. In order to produce programs which stand a chance of running on all systems it is necessary to restrict the functions tested to the 'core' words which are mainly control constructs or stack manipulation words. I have not tested any lower, byte level, words as these tend to be almost 'naked' machine instructions and one ends up Benchmarking the processor not the implementation. Similarly high level structures like strings and arrays are excluded because they are not implemented on many systems. Floating point extensions are becoming more widespread and could be a candidate for future addition.

Even having decided to stick to core words there were problems over standards. There are two major variants of the Forth core, the Forth Inc version and the Forth 79 Standard plus lots of 'eccentric' versions such as Transforth and Stackworks Forth. The differences are usually only a matter of names; there are equivalent words in most systems but they may be called by different names. I  have  chosen (with one exception)  to  go  for

The exception I mentioned is the word SP! which removes all the contents of the data stack. This isn't required in the standard though it is in fact implemented in a lot of 79 systems. The reason it's required is as follows. PCW's other Benchmarks, the Basic and Pascal, are analytical in the sense that by subtracting the timings of successive tests one can isolate the time due to a given instruction (not completely true for the arithmetic functions). We feel that this is a desirable feature which is why we haven't adopted catch-all tests such as Eratosthenes Sieve. (For a full account of Benchmarks see PCW Nov.)

Forth is so fast that most of the programs test 100,000 iterations (and that is barely sufficient for 'magnifier'). No Forth system in the world can hold 100,000 items on its stack and so the stack has to be cleared if we are to get a direct timing for any word which leaves a result on the stack. Hence SP! is required. I have deliberately placed it in 'magnifier' which is meant to be subtracted from the other timings as a constant overhead (thanks to Chris Sadler's Pascal BMs for the idea). If you want to run the BMs on your system and don't have SP! or an equivalent, you must write one; it hardly matters whether it's in machine code or high-level as it's part of the overhead. I had to write SP! for two of the systems timed here, PicoFORTH and GraFORTH. PicoFORTH keeps the stack pointer in a processor register; the definition in 8080 code is:-

: SP! SO @ 2  (SP!) ;

The word S0, which is present in most systems is a variable holding the address of the stack base; many systems also have SP@ which fetches the address of the stack top.

GraFORTH uses RAM locations and has the unForthlike PEEK and POKE so

I deliberately haven't included any timings for compilation as this is so I/O dependent; there would be no basis for comparison between disk and cassette based systems for example.

What of the systems timed here? Z-80 FORTH is a product of Laboratory Microsystems in Los Angeles and has established itself as one of the best CP/M systems available. It is based on fig-FORTH 1.1 recoded for the Z80. It features a first class screen editor, floating point extensions, and a true Z80 assembler and it has the ability to generate a new system for any RAM size of host with any required extensions included. All the high level source code is included and it uses a CP/M-compatible file format to store screens.

xForth is a British product from AIM Research of Cambridge, and also runs under CP/M. It has a 79 Standard kernel with lots of very advanced extensions. In particular, it has facilities for modular programming with local variables, run-time conditionals and conditional assembly (8080 assembler), and full CP/M file handling capabilities which can access, for instance, Wordstar files. Floating point and sequential files (with pipes and spooling) are available as extras. It has an even better screen editor than Z-80 FORTH which includes a global search-and-replace and user configurable control codes.

PicoFORTH is a 'kosher' product from Forth Inc, itself, distributed in the UK by Computer Solutions of Chertsey. Meant as an introduction to Forth programming rather than as a professional system, it is a smallish single-user subset of their multitasking polyFORTH. An 8080 assembler is provided but only the original Forth line editor which is rather spartan compared to the editors on the other systems tested. Although it boots from CP/M it does not use CP/M compatible files but 'pure' Forth blocks. This means you cannot, for instance, copy files with PIP nor interface with CP/M via system calls.

GraFORTH is a special graphics language, based on Forth, for the Apple II; it is written by Paul Lutus of Applewriter fame (notoriety?). It provides some very nice features for animated 3D graphics and music synthesizing. The demo programs impressed everyone who saw them, even given the limited resolution of Apple graphics. It is possible to draw a wire-frame picture using turtle graphics and then animate it by scaling, rotation and translation without any more drawing at all. As a Forth system it is rather eccentric with numerous wilful deviations from Forth practice which make it hard to come to or go from this to a 'standard' system. For instance, variables are handled in a Basic-like assignment statement eg, L 1 + > L and put their value rather than address on the stack when called (which is why I have no timing for 'variable'). The editor is based on the Apple Basic editor using the same ESC codes and line numbers; it is quite nice to use. No floating point or assembler is included. Unusually GraFORTH is directly threaded - ie, it compiles 6502 code rather than pointers into its headers; the effect on the time for 'dictionary-search' is very noticeable.

Working Forth is a teaching system from Mountain View Press of California based on standard fig-FORTH. Like picoFORTH, this is a 'pure' system which doesn't use CP/M files. It has a large number of screens of teaching-machine type instruction which have the nice feature that the student can come out into Forth and do exercises and then easily start at the point he/she left off (or indeed repeat a lesson). The quality of the teaching is high, if perhaps rather forbidding the total novice; it would be better to know Basic and best to know some Assembler before approaching it. It represents terrific value for money, though, because you get a full Forth system with assembler and editor (an enhanced line editor) which will keep you happy long after you finish the teaching course. They even give you the assembler source for the kernel on disk. The documentation is very rudimentary, however, as most of it is meant to be on the screen.

At the last minute before hitting the press I received a copy of Kuma Computers' Forth for the Sirius 1. This is a fig-1.1 based system written in genuine 8088 code, and as you will see from the timings it is indeed quicker than a 4MHz Z80 version except in

I hope that any Forth using readers will run the Benchmarks and send in their timings so that I can print updates on an annual basis as Chris does with the Pascal. Please specify what processor and clock-rate if you do this. Any suggestions for improvements or modifications will also be welcome.