[Design Application]
Forth Still Suits Embedded Applications
Although Sometimes Viewed Merely As An Interesting Relic, Forth Still Holds A Role In Today's Embedded Systems.
A number of compiler control words always execute. One of these is "colon" (:), which tells the compiler to start adding a new definition to the dictionary. The next word in the source then becomes the name of the definition and is followed by the words that make up that definition. Each of these words gets compiled in turn. The definition terminates when the word "semicolon" (;) is encountered in the source.
Once a word has been defined, it can be used to define further words. In general, words must be defined before they can be used. But definitions can be DEFERed, and recursion is allowed. You also can FORGET, edit, and recompile part of a program without changing the earlier parts of the code.
The "fetch next code address and call it" manner in which Forth executes its programs takes slightly longer than calling a subroutine or executing in-line code. A Forth program will theoretically run more slowly than a compiled program in another language. (Some Forth compilers generate executable machine code and don't have this overhead.) In practice, the efficiency of Forth's arithmetic and the absence of OS calls and overhead, such as garbage collection, make Forth's execution fast as well as predictable. It also handles interrupts very smoothly. And Forth needn't save the context, since it's already on the stacks.
Forth's method of execution may result in slower operation than other compiled code, but the code itself is more compact. A Forth word compiles either to a token or to an address and so occupies only a byte or two in memory. An embedded Forth usually incorporates its own operating system. Even so, Forth and Forth programs are very compact. A compiler can be written in 1200 lines, which compiles to about 6 kbytes. A run-time kernel need take no more than 2 kbytes. For many years, I used a commercial Forth which ran under DOS on a PC. It contained a built-in source editor but occupied only 15 kbytes of memory. Each Forth word occupies one or two bytes, and a line of code may contain four or five words. A microprocessor with a 64-kbyte address range can run a 5000-line program.
A Run-Only Option During compilation and program debug, Forth needs to keep a diction-ary of word definitions available. But in the final product, the dictionary names are just so much wasted space. They could, however, contain proprietary information. Fortunately, most Forth compilers allow you the option of creating a run-only version of the code. This version contains neither the dictionary structure nor the definitions of any standard words that haven't been used. This not only shortens the code, but also makes reverse engineering much trickier.
If you're going to write your embedded application in Forth, you have two approaches from which to choose. You can write and compile the program on a PC using the PC's disk and editing facilities. Then, just download the program to PROM, RAM, or EEPROM in the target system. You also may be able to emulate program execution on the PC.
The second alternative is to use the PC simply as a dumb terminal and to compile your program as you create it on the target system itself. This alternative requires that the target have some sort of serial port and enough RAM space to contain the Forth compiler. Yet it makes for vastly easier debug, because the code being tested is running at normal speed and interacting with the target hardware.
This second method also makes Forth a useful tool for debugging prototype hardware. It takes only moments to write a word to exercise a particular port bit, for example, to see where a signal gets lost on the board. I've also found Forth to be the perfect language for writing production test and debug programs.
There should be no trouble getting it to run in your prototype system. Forth has been implemented on just about every microprocessor that's ever existed. Yet it runs most efficiently on processors that support two stacks and have a word length that matches the width of the parameter stack. A microcontroller with enough on-chip RAM to implement the stacks will run Forth particularly quickly.
Time and again, this platform's flexibility in implementation has been demonstrated. In 1985, Charles Moore, who invented Forth in the late 1960s, used a gate array to build a single-chip Forth engine (see "Fast Processor Chip Takes Its Instructions Directly From Forth," Electronic Design, March 21, 1985, p. 127). This design was further developed by Harris Semiconductor as its RTX 2000 series of chips which, unfortunately, are no longer available in production quantities.
Forth also has proven itself in many embedded applications. The Magellan probe's radar pictures of Venus passed through a data-block handler that I designed. It was controlled by a Forth program running on a Z-80. I wrote its operating system and, in about two weeks, taught a hardware engineer enough Forth to write its 2000-line program. We used a PC running a Forth program for the system tests. Whenever the customer dreamed up new tests, it was a matter of minutes to incorporate them into the program.
On projects in which the final program was written in another language, I've used Forth as an executable program design language (PDL). Once the program was debugged in Forth on a PC, it was relatively easy to recode it in assembly language, for example. I'm currently implementing a tokenized Forth on a PIC microcontroller.
Reprints
