Any terminal can serve as a console and is incorporated into the Forth system by either selecting previously written sub routines or writing new subroutines to do the following: (1) clear the screen and home the cursor, (2) clear screen from cursor to end of line, (3) clear screen from cursor to end of screen, and (4) position cursor at screen coordinates x, y.

Forth programs are incrementally compiled from either the console key board or disk file. High level Forth contains structured control constructs of BEGIN .., UNTIL, BEGIN ... WHILE CASE ... OF ... ENDOF ... ENDCASE, DO ... LOOP.

Forth contains subroutines for number conversion, string processing, I/O for matting, as well as other generic tasks that make high level Forth similar to Basic in terms of the number of services.

Assemblers are frequently written in a language other than assembler, but in the Forth system assemblers are written in high level Forth and assembler routines incrementally compiled. As soon as a subroutine has been assembled, control is returned to the Forth operating system, and the subroutine is available for use by any other program. This "integration" contributes greatly to Forth's portability and speed.

Forth systems incorporate software development tools commonly found in other systems as well, such as full screen editors. Subroutines written in either Forth high level or assembler language interface to other operating systems' file systems and utilities, for example, PC/ MS-DOS and CP/M.

Forth hardware development system. Any specialized microcomputer system can be transformed into its own Forth development system by adding additional EPROM and RAM to contain a Forth operating system and development applications code. Two asynchronous communications elements provide the terminal and disk ports required by a Forth operating system. The National 8250 asynchronous communications element is attractive for the disk interface because it supports baud rates to 56 Kbits. The Intel 8251 A Usart works well at 9.6 Kbits with an 8085 Forth development system (Figure 2).

The strategy for producing ROMable application code is to keep development code in a disk file on a general purpose microcomputer for compilation onto the target Forth development system. A mini full screen editor on the target Forth development system is used to make small changes in the applications source code while a more powerful full screen editor residing on the general purpose microcomputer is available for extensive editing.

Once the application code is operational, it is added to the target Forth operating system source code. All sub routines in the Forth operating system unreferenced by the application code are ''commented out'' and the resulting minimum sized application source code file is cross compiled onto the target system. A minimum sized, runtime ROMed application binary file results (Figure 3).

Cost comparisons. Hardware costs of the Forth approach compared to microcomputer code development, either on supermini computers or microcomputer development systems, is one to two orders of magnitude less. All that is required is a target hardware system with additional EPROM and RAM and two serial I/O ports, a general purpose disk-based microcomputer an RS-232 connected EPROM programmer, and an inexpensive terminal.

The Forth development system software is an order of magnitude less costly than other systems. A cross compiler and a target source ready to be modified can be purchased for less than $500. No license fees are paid on reselling binaries produced by a cross compiler. All source code, with the possible exception of the Forth base, is supplied with a Forth development system.

Application code developed on a Forth development system takes, perhaps, an order of magnitude less time for moderate or large microcomputer applications than on other microcomputer development systems because: (I) The hardware for a Forth development system is so inexpensive that each member of the application code development team can have a personal system; (2) It takes only a few seconds to modify and test a software change in either assembler or high level Forth code because of incremental compiling and immediate loading and linking. (3) Code is taken from the operating system, Forth language, or utilities for use in the application code rather than being rewritten (Forth software support for mathematical peripherals or coprocessors, graphics, communications, etc., is available in source code at a reasonable cost).

Size and performance of applications code.  Forth produces minimum sized applications code. The reason is that Forth programs are composed of small subroutines. Code is not redundant. Pascal and C, for example, include redundant loop code each time they are coded.

Forth linkage conventions exact about a factor of six speed penalty for high-level Forth applications code compared to the same code written in assembler. However, in many applications most of the work is done in a small part of the code. The formal Forth subroutine linkage conventions can be discarded in favor of simple assembler calls for those parts of the code requiring speed. Examples of invoking high-level and assembler Forth subroutines from Forth and invoking high-level Forth subroutines to produce the output in Figure 4 are seen in Figures 5 through 8.

The screens in Figures 5 and 6 were written in Forth-83 for an Intel 8086/88 host while those in Figures 7 and 8 were written in fig-Forth for an Intel 8085 host. Both programs produced the output seen in Figure 4.

If a Forth application code does not run fast enough on a processor, changing the processor to a faster one could be a solution. The assembler code subroutines need to be rewritten for the new processor but most of the high level code remains unchanged. Applications code is perhaps the most portable of any language, because Forth is an operating system, job control language, high-level language, linkage editor, loader, and contains a host assembler capable of macro and conditional assembly written in Forth’s high-level language.

Forth, C, Pascal, Basic, and assembler comparisons.   C, Pascal, and assembler are not operating systems. They are not job control languages. Pascal does not contain an interactive assembler.

Basics are frequently operating systems and job control languages. Basics, like Forth, are interactive, but do not have an interactive assembler; they rely on PEEK’s and POKE’s for some hardware interfaces (Forth contains port fetch and store subroutines similar to PEEK and POKE for accessing I/O ports from high-level Forth). Basic application code frequently runs slowly, and Basic code is perhaps the least portable. Basics are more closely related to Forth in philosophy and sometimes in implementation (Sinclair ZX81Basic was partially written in a floating point version of Forth) than most other languages.

Forth was designed as a tool for producing commercially competitive applications code. C and Pascal were not designed for this. While Basics share many of Forth’s attributes, applications written in Basic run too slowly, and it is difficult to cull unused Basic system subroutines to produce a minimum-sized application code.

Assembler lacks the coding and module testing speed of an interactive Forth assembler. Assembler coding can lead to coding modules in assembler that are better coded in a high-level language.

The cost advantage of using the Forth programming environment for producing ROMable applications code for inexpensive microcomputer systems is so great as to make attempts using other operating systems and languages noncompetitive.

W. H. Payne
Digital Subsystems I,
Division 2311
Sandia National Laboratories
P0 Box 5800
Albuquerque, NM 87185

W. H. Payne is currently a project leader at Sandia. He received his BA degree from Whitman College in 1959 and MS and PhD degrees from Purdue University in 1961 and 1964.