[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.
No single solution exists for embedded programming. Projects differ too widely in scale. Real-time signal generators may need every instruction cycle counted, but the programs take only a few hundred lines of code. For such applications, assembly language is the only way to go. Other jobs require extensive user interfacing and hundreds of thousands of lines of code. There, the most economical solution is often a ready-built single-card PC, programmed in C and running an operating system.
For mid-sized applications that need only a few thousand lines of code, however, you may find that you're using an expensive microprocessor and a lot of PROM. And it's not because the task really needs it, but because the operating system and the language demand it. In such situations, choosing Forth lets engineers produce compact and reliable code quickly, run it on an inexpensive processor, and reuse the results in later applications.
Forth isn't a new language. It's been commercially available for over 25 years and has its own ANSI standard (X3.215/1994). But it's not widely used. There are probably fewer than a hundred full-time Forth programmers in the country. Instead, C is the language of choice.
Programmers learn and use C because everyone else uses it. Managers specify C for their projects because C programmers are easy to find. Yet if you talk to hardware engineers rather than programmers, you'll find many that are familiar with Forth and eager to use it. That's a point in Forth's favor because, in embedded-systems development, an engineer who understands the hardware is often a more effective programmer than a computer-science graduate who would rather be writing compilers.
Forth is a powerful language, but its syntax is simpler than Basic's and much simpler than C's. Despite its simplicity, you can extend the language to meet any requirement. You're never limited to what some compiler writer thought you might want to do. As with assembly language, you have to keep in mind what's happening at the hardware level. But beyond that point, Forth is an extremely easy language to learn and use.
If Forth were just another computer language, it wouldn't stand out from the rest. But it's conceptually different. For a start, the Forth kernel acts both as an interpreter and a compiler. So Forth programs run about as fast as if they were compiled, yet can be written and tested interactively. Any routine in a Forth program can be tested from the keyboard without a symbolic debugger. This tightly coupled code/test loop makes programmers extremely productive.
Forth achieves this seeming miracle by eliminating parsing. Every word in the source represents a single operation. (Parentheses delimit comments, not pending operations. Pending operations exist but are rare in Forth.) Every word knows where to go for its input parameters, how to process them, and where to leave the result. If you type a word at the keyboard, it will execute. You can test a word with any input parameters you please to check that it always works.
To write programs in Forth, you create the definitions of new words, extending the language until it can handle the task at hand. Each definition is made up from other words. Some of these words come from the library of predefined words, such as arithmetic functions, which form Forth itself. Others will be words that you yourself defined earlier in the program (see "A Sample Of Forth"). Forth makes no distinction between library and user-defined words. The highest-level word is the application program itself. Thus, Forth programs are designed from the top down but written and tested from the bottom up. Think of it as an executable program design language.
You can do anything in Forth that the hardware itself can do. In effect, you write your own application language. A program to drive robotic arms would have words to turn an arm, while a benchtop instrument would have them to write characters to a display. Each new Forth word is inherently a reusable program module. On your next project, you can reuse the same words, thus steadily increasing your productivity.
Reusing words is easy even if you need to move to a new processor architecture. Only 80 or so of Forth's predefined words call routines written in the machine code of the host processor. The rest are written in Forth. So the language and all of your word definitions are easy to port to a new microprocessor. Only those 80 machine-code definitions—less than 2000 bytes—need to be changed.
That productivity enhancement applies to the entire project, as well. With adequate partitioning of the program's functions, coding can be divided amongst as large a team of programmers as may be necessary. Once every low-level word has been written and tested, the higher-level code is almost sure to work. Integration and maintenance of code also is easy. Word names in Forth can be long and should be descriptive of their actions. Good Forth is almost self-commenting. Because definitions tend to be short, it's much easier to follow the program flow in Forth than in other languages.
Forth programs have a high degree of structure. All of the usual IF, ELSE, WHILE, and LOOP operators also are Forth words, but their usage is much clearer than in most languages. For example, comparisons are distinct from the actions to be taken. A comparison word creates a flag; a decision word then uses that flag. There's nary a GOTO in sight, unless you care to define one.
Reprints
)
