grt@twitch.UUCP ( G.R.Tomasevich) (06/19/86)
This comparison is a response to recent questions about Forth utility. I do not know standard Forth, but I have worked on two dialects which are quite different, based on what I read in a Forth book that I picked up at a computer show. My first extensible dictionary compiler experience was on a Nova 1200 computer for which a then Columbia U grad student, Gordon Chin, and I wrote a Forth-like language while Charles Moore was still at Kitt Peak doing the PDP-11. We used the Nova assembler to do the primitives and the language for its extensions. The computer controls a radiotelescope drive servo and reads the data from a multichannel receiver. We did not try to do a Nova assembler in the language. The system worked quite well and included overlays once we ran out of memory. My second experience was here at AT&T Bell Laboratories when I wrote a similar language in C. That is, the primitives are C functions, while all extensions work as they do in Forth. I used it originally for an 8086 simulator, but now instead in an interactive graphics program. It really gives me a comparison of Forth vs UNIX/C as programming and operating systems. I call the program 'dicom' for dictionary compiler, except that the graphics program has several names, such as 'bplot', 'hplot', etc all linked to the same file. The first letter tells it what default terminal type to assume. Comparisons: Compilation: The C code resides in several files, and there are makefiles for recompiling when there are changes. If I change a primitive or add a new one, say, so that a C file is out of date, then 'make' does the usual business of recompiling that file, putting the object file into an archive, then relinking all of the .o files into the executable file. This takes quite a long time. If I am doing a throwaway program for a one-time calculation, I can make a small dicom file with the necessary macros, bring up the program, incrementally compile that small file, and run, all rather quickly. The alternative would be to write a C program and stick it into some core program which provides the input, output, etc (the interpreter, in effect). Thus, quick-and-dirty programming is much faster in the Forth-like language. Execution speed: C wins here, partly because this is not a true Forth. The stacks are simulated as arrays in the C program, and there is the overhead of multiple C function calls as the virtual machine walks through the list of pointers in the macros. For the graphics, I pushed the tight inner loops into C functions. Code size: The threaded code of the dictionary is obviously much more compact. The C code part of the program quickly required me to use separate I and D space on the original PDP-11 implementation, while the amount of functionality in the dictionary is quite substantial compared to the amount of memory it uses. The dictionary is probably as compact as in true Forth; the header is a structure with a pointer to the next word, the name of the word, the length of the name, and a pointer to a function to execute for the word. This latter pointer is needed in separate I and D. One cannot execute code from the vocabulary, but rather access pointers to code located in the instruction space. Which language/system? I would prefer Forth for real time hardware control. UNIX has to be contorted to do the job. We did an 8088 processor for some hardware and used C but no real operating system; just a perpetual loop doing tasks round-robin and on interrupts. We ran out of memory but not processor speed, so Forth would have been nice. We were handed a program from a previous product that we had to use. We are about to do some 68010 processors, and I bought an HP 64000 development system for that. I guess that forces us to use C, though we certainly will not run UNIX on those either. -- George Tomasevich, ihnp4!twitch!grt AT&T Bell Laboratories, Holmdel, NJ