Forth as a Diagnostic Language Mitch Bradley Kinds of diagnostics: 1. Prototype Bringup 2. System Troubleshooting 3. Board Test (for repair of boards) 4. Functional Test (for verification of boards) 5. System Verification Characteristics of diagnostics: Types 1, 2, and 3 need to be highly interactive, because it is nearly impossible to build a non-interactive program that anticipates every possible problem. A menu-driven user interface is very good for type 3, since by the time the board is in pro- duction, the common failure modes ought to be well understood. Menus are good for 1 and 2 also, but they do not solve the whole problem; when troubleshooting difficult problems, it is desire- able to be able to quickly construct a custom test to check out a theory that has just occured to you. A language that is inherently interactive is very nice for this purpose. Types 4 and 5 do not demand user interaction, although it can be useful as an option. Type 5 needs multi-tasking, in order to catch problems with interactions between different system com- ponents. For all kinds of diagnostics, it is very nice to be able to run with parts of the system disabled so that faults may be iso- lated. For example, sysdiag is very good at beating up the sys- tem and breaking it, but it is often extremely hard to figure out what went wrong when sysdiag finds a failure. In general, diag- nostics that run under Unix are difficult to use for fault isola- tion, since Unix tends to depend on most of the system resources. Strong Points of Forth Highly Interactive March 20, 1986 - 2 - Forth is by its very nature interactive. Any subroutine in the whole system can be executed at any time from the key- board. If desired, programs may be typed-in at the keyboard. There is a built-in interactive assembler, so the user has total control of the machine. It is also easy to build menu-driven programs in Forth; it has a facility similar to "termcap", whereby display-oriented programs can run on just about any kind of terminal. Built-In Multitasking Sun's Forth system has multitasking. Tasks can be started, stopped, and controlled easily from the keyboard, or automat- ically if desired. Forth tasks all run in the same address space, so they can easily communicate with each other using shared memory. Menu Package Sun Forth has a set of routines that make it very convenient to build menu-driven programs. Minimal Working Hardware Needed The only hardware that Forth absolutely needs is the CPU, some memory, and a terminal (a Sun monitor, a Televideo, or whatever). There is even a version that runs out of PROM on a Model 50, using the video memory as its RAM. This version retains all of the interactive features, including the assem- bler. C Subroutines Sun Forth can dynamically load and execute subroutines writ- ten in C. The C subroutines can be interactively executed from within Forth. These characteristics combine to make Forth an exceptionally powerful debugging tool. Many times I have been able to quickly "zero in" on a problem because I could try out ideas or theories in a matter of seconds. Being able to interact with the software and hardware without needing to have Unix running allows con- venient debugging of peripherals like disks. The simple multi- tasking allows hardware interactions to be isolated quickly. Several times I have been able to reduce the mean time between failures from once a day with Unix to once a second with Forth. I was able to do this because Forth let me quickly try out several possibilities, and it let me directly control selected subsets of the hardware. Problems with Forth Most People Don't Know Forth Forth is certainly not as widely known as C. Forth is not difficult to learn and the payoff is great. Forth is a Write-only Language? People who know Forth find it quite readable. Forth has a March 20, 1986 - 3 - basic vocabulary of about 150 words, which you need to know in order to easily read Forth. Of these words, nearly all are very simple, and are easy to remember (for example, "+" means add and "if" is a conditional). In languages like C, it is frequently possible for someone who doesn't know the language to read a program, so long as he knows several similar languages. This is because there is a whole class of languages that are basically the same. Forth is syntactically very different from the C/Pascal/Fortran class of languages, so you can't necessarily read Forth just because you know C. Once you learn Forth, it is readable. Of course, it is pos- sible to write unreadable Forth code, but that is true of any language. Forth doesn't fit in well with Unix? Sun Forth does! With Sun Forth, programs are edited in nor- mal Unix files using vi or Emacs. Forth programs can call C-library subroutines and do Unix system calls. Most of the limitations of microcomputer Forths do not apply to Sun Forth, which makes use of the full address space of the 68000. Forth is an interpreter, so it must be slow? When a Forth subroutine is defined, it is incrementally com- piled into the system, so it does not need to be re- interpreted later, as in, for instance, some Basic inter- preters. The net result is that Forth programs run a little slower than the same program written in C. In practice, I have not found this to be a problem. In those few cases where I have needed something to run extra fast, it has usu- ally been a matter of a few minutes work to code a critical loop in assembly language. The built-in assembler makes this very easy. In any case, diagnostic work hardly ever pushes the speed routinely available from the Forth system. Companies which use Forth ROLM Corporation uses Forth for all of its diagnostics. The switch to Forth occurred after I left ROLM for Sun, so I don't have firsthand experience, but a friend there tells me that peo- ple are very happy with the switch. The Stanford Linear Accelerator Center has been using Forth for board diagnostics and process control for many years. Forth's main niche is in control applications. Many of the world's large telescopes are controlled by Forth programs. Forth has been used very successfully in robotics applications and in control of scientific apparatus. These applications have much in common with diagnostics, namely, the user needs absolute and pre- cise control over the hardware, and there is very little desire March 20, 1986 - 4 - to "multiplex" access to resources between competing users, as is the case in a timesharing system. March 20, 1986