1985 Rochester Forth Conference Proceedings
on Software Productivity and Project Management.

Introduction

Lawrence P. Forsley

Invited Papers

The MAGIC/L Programming Language

Arnold Epstein and Claire H. Gilliatt
Abstract

When Forth was created in the early 1970's, it represented a major change in the way programmers could think about their machines and the programming process. It allowed fully interactive coding and provided for almost unlimited extension of the environment. This has undoubtedly been an important breakthrough. However, there are a number of characteristics of Forth which can be problematic, especially where group productivity is concerned. Among these are its reverse polish notation and the tendency towards highly dialectical programming. MAGIC/L, developed by Loki Engineering, Inc., combines the fundamental advantages of Forth with a stable syntactical structure and a full set of programming constructs, increasing efficiency in programming and project management.

Forth as the Basis for an Integrated Operations Environment for a Space Shuttle Scientific Experiment

Henry M. Harris
Abstract

Over a period of three years, a Forth-based system was developed by JPL (Jet Propulsion Laboratory / California Institute of Technology) for the operations of a major scientific instrument onboard the Space Shuttle. The software had to meet a very demanding operations environment where the interactiveness of the software was not merely desirable but essential to the success of the mission. Forth was chosen for its capability of integrating divergent software needs into an interactive package. The mission flown in October 1984 was beset with numerous hardware failures and challenged the capability of the system to its fullest.

HFORTH: A High Level Business Language in Forth

Pierre Moreton
Abstract

A presentation of some features of HFORTH, a high level business language written in Forth, some recent application and the extension to THE ROBOT, a menu driven program generator.

Fifteen Programmers, 400 Computers, 36,000 Sensors and Forth

Elizabeth D. Rather
Abstract

A large, recently completed Mid-East Airport featured in its design a powerful, integrated computer system incorporating security and access control, fire and life safety monitoring, environmental monitoring and control, power distribution, fuel farm monitoring, waster distribution, control of runway lights, and numerous related applications. The system is being supplied by AVCO Corp., and is programmed in Forth by a team of programmers form FORTH, Inc., and AVCO. This paper discusses some technical and management highlights from this experience.

Presented Papers

Pragmatic VLSI Design Environment

Thomas Almy
Abstract

This report consists of the overview of the VLSI design "environment" created in Forth. The PRIDE program has been run on computers ranging in size from a TRS-80 Model I to a VAX-11/780 and has been used for the design of over 10 ICs.

Top-Down Design in Forth

James Basile
Abstract

Top-down design and coding practices are central to effective software engineering. Forth provides a programming environment which readily can be modified and expanded to suit particular needs. This paper examines the relationship between Forth as a programming environment and the use of top-down design and coding.

Forth Implementation in a High-Level Language

James C. Bender
Abstract

A prototype Forth interpreter has been implemented in Ada as a research project. The Forth interpreter is written to take advantage of Ada features, such as range checking, exception handling, and utility packages for string handling and numerical operations.

Measurement of Interrupt Response Time of PDP-11/44 and PDP-11/23 Computers with a CAMAC Interface

J. R. Birkelund, J. A. Abate and T. S. Lund
Abstract

Comparison of interrupt response time for PDP11/44 and PDP11/23+ machines, using the Forth programming language, is presented. The interrupt response of the machines with Forth implemented as a stand-alone operating system is compared with an implementation of Forth running under the RSX11M operating system. The comparisons have been made on systems operating CAMAC parallel interface busses, both as single bus controllers (IEEE 583) and as parallel highways (IEEE 596), which require a branch driver interface.

An Implementation of MC68000 fig-Forth under Unix

Peter R. Blake and Nick Solntseff
Abstract

The Department of Mathematical Sciences (the previous home of Computer Science at McMaster University) acquired three Pixel-80 computers in January 1984 for graduate and senior undergraduate teaching. The computers incorporate a MC68000 microprocessor and operate under the Unix operating system. The present paper summarizes the work done to implement Forth on the Pixel-80s.

Expanding the Forth dictionary beyond the 64K limit by using 'Bodiless' Code

Robert Boni
Abstract

At the Kodak Research Labs (KRL), experimental test beds are controlled from Forth. The most complex test beds require a Forth system with a dictionary larger than 64 kilobytes of memory will allow. An existing Forth system, modified to produce bodiless code, now supports a dictionary of several megabytes. These modifications, which generate the bodiless code, provide a method to increase the dictionary space of a Forth system running on a computer with memory management capabilities.

Improving the Understandability of Forth Code

John Bowling
Abstract

One of the most often vocalized complaints about Forth is that it is unreadable, and therefore unmanageable because no one but the original author understands it. An example of this is metacompiling: One of the least understood and most complex functions in Forth.

A Window System

Mitch Bradley
Abstract

This simple window system can be used with most ASCII terminals. Arbitrary rectangular regions of the screen may be defined as windows. Output directed to a window will be confined to that region of the screen. By assigning a different window to each task, tasks may conveniently share the screen without worrying about each other. The system access to the keyboard so that multiple tasks may simultaneously request input without confusion.

An Alternate Forth Dictionary Structure

James C. Brakefield
Abstract

The data structures used for definitions and the word search of Forth can facilitate various utilizations of the same. My goal is completeness and efficiency.

Constants or literals are stored separately. This is so they can be hashed. The concept of a constant is enlarged so that the code string is a constant in the same sense as a text string. A constant is something which is self-identifying and unchanging at the textual level.

A colon definition is then a pairing of a code string with a name. Only pointers to the two "constants" are kept in the definition entry (a pointer to the name string and a pointer to the code string).

The various constant and definition records are implemented with tagged fields. This allows inspection of the entire record by any routine processing a pointer into any field of the record.

Additional optional fields are: Reference count, Comment pointer, Input type list pointer, Result type list pointer, etc.

Conversion of a Token Threaded Language to an Addressed Threaded Language

Bob Buege
Abstract

After becoming spoiled by almost four years of experience with a token threaded language, I find it difficult to imagine ever going back to an address threaded language. Token threading gives me the flexibility of a metacompiler without the complexity. All code is relocatable. I can modify or delete words at the beginning of the dictionary without recompiling. I can eliminate the words not needed for an application before burning the application in ROM, and since garbage collection becomes a trivial problem, I can even eliminate the need for screens by decompiling object code and doing all my edition from RAM.

Many of the tools which I have come to depend on would be difficult or impossible to adapt to an address threaded language. However, address threaded languages do have a speed advantage over token threaded languages for most applications.

A compromise has been achieved which allows me to do all my development work in a token threaded language and then use self-modifying code to convert the language into an address threaded language for increased speed when the project is completed.

A Direct Threaded Code TTL Control Unit

Jack Calderon
Abstract Only

A hardware design for a control unit is presented which utilizes TTL logic and fast CMOS Static RAM to implement a very fast version of DTC. The control unit is capable of sequencing the operations required for NEXT in one memory cycle and for DOCOL and SEMI in two memory cycles. A prototype of the control unit is currently being tested for performance evaluation.

A Forth-Based Object File Format and Relocating Loader used to Bootstrap Portable Standard Lisp

Harold Carr and Robert R. Kessler
Abstract

For a quarter of a century much Artificial Intelligence research has been accomplished using Lisp as the implementation language. Portable Standard Lisp (PSL) was created to support research activities on a wide variety of processors and operating systems. To aid in porting PSL, we developed an ASCII object file format whose relocation directives are essentially Forth language statements. A Portable Linker is then used to directly link compiled Lisp code normally dependent on the Lisp runtime system. Finally, since the object file contains Forth statements to handle final relocation of segments, we wrote a relocating loader in Forth to load and execute theses "exported" Lisp programs. The PSL runtime system is ported by processing it with this system as just another exported program. This paper discusses the Forth-based object file format (which is general enough to handle other languages besides Lisp) and the Forth-based relocating loader.

A Multiprocessing Computer System Composed of Loosely-coupled Forth Micro-chip Modules

Gabriel Castelino and Richard Haskell
Abstract

A Multiprocessing Computer System consisting of loosely-coupled Forth micro-chip modules is currently being developed at the School of Engineering and Computer Science at Oakland University. A network of 16 modules has been designed. The modules do not share any common memory and communicate with each other over a global bus -- an 8-bit parallel bus with seven control lines. The system uses a layered protocol structured on the OSI Reference Model. The network is designed to support different types of micro chips operating at different speeds. The software support at the physical and data-link layers will have to be modified for the different types of micro-chip modules.

In such a system, it would be desirable for one module to execute a word that has been defined in another module in the system. This is referred to as a Remote Procedure Call (RPC). In the system being developed, calls of this type are handled by the RPC layer which sits above the Data-link layer of the OSI model. The Forth words defined at this level are independent of the type of micro-chip being used.

A Microcoded Machine Simulator and Microcode Assembler in a Forth Environment

Alan Cotterman, R. Grewe and Robert D. Dixon
Abstract Only

A Forth program which provides a design tool for systems which contain a microcoded component was implemented and used in a computer architecture laboratory. The declaration of standard components such as registers, ALUs, busses, memories, and the connections is required. A sequencer and timing signals are implicit in the implementation. The microcode is written in a Forth-like language which can be executed directly as a simulation or interpreted to produce a fixed horizontal microcode bit pattern for generating ROMs.

The direct execution of the microcode commands (rather than producing bit patterns and interpreting those instructions) gives a simpler, faster implementation. Further, the designer may concentrate on developing the design at a block level without considering some of the implementation details (such as microcode fields) which might change several times during the design cycle. However, the design is close enough to the hardware to be readily translated. Finally, the fact that the same code used for simulation may be used for assembly of the microcode instructions (after the filed patterns have been specified) saves time and reduces errors.

A Micro Based ASW Trainer in Forth

Robert H. Davis
Abstract

The author's group at the Naval Surface Weapon Center is engaged in the development of a low cost desktop trainer for NAVY ASW Acoustic Sensor Station Operators. Each device is based on a Zenith 150 microcomputer, with the software being developed using ROHDA-FORTH, the author's personal implementation of the Forth language. Brief descriptions of the system being simulated and the Forth based simulation are given. The paper then focuses on the productivity aspects of using Forth in the development effort. Particular areas discussed are the value of very high level coding (using the ROHDA-FORTH Data Structures and Symbolic Function compilers) to expedite development of all coding for an initial pass, and used of trace facilities to achieve extremely rapid code development. Selected examples of coding form the project will be used to illustrate the use of the high level programming constructs and the trace facilities used in the software development.

A Machine to Implement a Generalized Forth Environment

Robert D. Dixon, R. Grewe, T. Rocheleau and Alan Cotterman
Abstract Only

A microceded design of a machine to implement a 32-bit Forth has been simulated. The addressing is segmented so that storage allocation and deallocation is quite general. Garbage collection and compactification of memory are supported. The design of the instruction set is in the spirit of the RISC (Reduced Instruction Set) machines, allowing stack operations and indexed access directly into the stack to produce a frame or register-like environment.

The aim of the project is to produce a fast machine, which while supporting the traditional Forth environment, will allow more traditional parameter passage and access; it will also support integrated packages of languages and applications.

A slightly higher level implementation of a similar Forth kernel has been implemented by another group on a VAX and that implementation is available.

A Forth Implementation of the Heap Data Structure

William B. Dress
Abstract

The use of the heap for memory management provides the Forth programmer with a versatile tool. Its use speeds program development at the conceptual level by allowing the program designer a means to consider dynamic arrays, garbage collection, and overlays; and at the implementation stage by providing a framework for easy manipulation of data structures.

Real-Time State Machine Implementation Programming Techniques

Randy M. Dumse
Abstract Only

Experienced system designers readily admit that state diagrams are more useful in describing real-time automina than flowcharts. This is particularly true during the system definitions, when the action of the machine are described in terms of the inputs and outputs and time conditioned responses. These same designers would be hard pressed to name even one source describing any method for generate programs from state diagrams. State diagrams have historically been the tools of the hardware designer, which may explain why published materials on conversion methods from state diagrams to computer programs (flow chart, pseudo-code or high level language routine) are not widely available. This paper will attempt to identify why high level language programmers have lined up behind the flow chart (or pseudo-code equivalent) and left state diagrams to hardware engineers and a few stubborn assembly language programmers. It will also explain at least one version of the rules used to design using state diagrams, and how to program from these drawings.

A Forth Based Iconic Interface

Mohamed Erradi and Claude Frasson
Abstract

This paper highlights the power of MacForth as a high performance interactive programming environment for the Macintoch Computer, in developing an interactive interface for integrated databases. We present the main specifications and some implemented commands of a command language based on icons. Objects to be manipulated are represented by icons. Properties are attached to each object and are also represented by icons.

Interactive Videodisc Control and Computer-Based Training on the Apple Macintosh

Nick Francesco
Abstract

This paper presents the use of a microcomputer to control the action of the videodisc player. This has the great advantage of allowing an instructional designer to create a complete course for the student, with remediation and branching, that can either be run by the instructor in a classroom setting, or by the individual student at his or her own pace.

The Design of a Low Cost CAD/CAM System

D. French and B. Hughes
Abstract

There are a number of CAD/CAM systems available to Industry today, ranging in cost from approximately $25,000 to $300,000. These systems vary greatly in the hardware and software facilities which they offer to the potential user. The small companies that make up the majority of the manufacturing industry cannot, in general, afford the highly sophisticated systems. In many of these companies, the need to carry out complex analyses is not necessary. However unless the small company has access to this new technology at a reasonable cost, it will be unable to manufacture its products on a competitive basis.

Microcomputer Control of a Machine Tool

D. French, R. Rier and B. Hughes
Abstract

The requirement of a low cost Controller for Machine Tools, which could perform similar functions to more expensive systems, is necessary if small companies are to be able to use sophisticated techniques for manufacture.

At the University of Waterloo, in the Department Engineering, a number of systems have been designed. The systems have varied both in the hardware, and software used.

DEBUGGER: The Design of a Test Aid to Support the Development of an Embedded Computer System

Harvey Glass
Abstract Only

The paper describes the design of a Forth-based debugging aid that has proven useful in the development of a sophisticated real-time microprocessor based controller. The controller provides an interface between a militarized intelligent terminal and 1) an auxiliary bubble memory, and 2) a local area network. The computer programs supporting the controller operate in an interrupt driven multi-tasking environment. The test support facility was implemented to assist in identifying and correcting programming errors in the controller software. We will discuss our experiences in the design of this tool and how it provides a programmer with a means of gaining visibility into the product under development.

Exception Handling in Forth

Clifton Guy and Terry Rayburn
Abstract Only

Forth relies on the discipline of the programmer to provide the benefits of structured languages: readability, predictability and modularity. A difficult class of problem for structured software is the handling of exceptions to the control flow, including errors. Even in properly designed software, a low level module may detect a condition whose proper resolution resides on a higher level. We describe a general implementation for exception handling in Forth that hides the inherent structure violation within a readable control structure which allows return from any nesting depth of Forth words and control structures. Further, this structure is itself nestable to any arbitrary depth.

Local Variables

John R. Hart and John Perona
Abstract

There are some cases where the number of variables inside a procedure exceeds the maximum that can be easily accessed with simple stack operators.

Local variables are proposed to free programs from stack thrashing and spaghetti like manipulation that can occur in programs with a large number of stack variables.

Forth Automates Intrinsic Viscosity Determinations

David J. Hooley
Abstract Only

An automated system for determination of the intrinsic viscosity of polymer samples has been implemented in the Analytical Laboratory at SOHIO.

Multi-tasking Forth facilitated the implementation of the project and simplified software by enabling independent operation of the tasks. Conventional terminal mode tasks were used for the status display, operator interface, bar code printer and data storage on a remote computer system. Four additional tasks were responsible for control of, and data acquisition from, four viscometer tubes. All of these tasks share a single copy of the control and data acquisition software. Individual data buffers are used in each task to hold task specific information.

Timing for each channel was done in software rather than by individual real time clocks. The 1 KHz interrupt rate of the system's fixed period clock provided more than the required accuracy of 10 ms.

Report generation, calculations, plotting of data and data acquisition were accomplished with memory resident software on a 60 KB LSI-11/2 processor with a total hardware cost of $10,000. Vendor supplied operating systems would have required at least an LSI-11/23, 256 KB memory and a 20 MB disk system. These systems would have also required individual real time clocks for each channel to achieve the necessary timing accuracy. The cost of such a system would have been several times that for the Forth based system.

System Development via Prototyping in the Analytical Laboratory

David J. Hooley
Abstract Only

In the appropriate situation, the prototyping approach to system development offers lower risks to the software development manager than the traditional structured approach because it is more likely to produce a system meeting clients' needs. The interactive process of prototyping will be examined using the system for determination of intrinsic viscosity of polymers, implemented in the Analytical Laboratory at SOHIO, as an example.

The system evolved into the current form through three major prototypes. Although a number of details still need revision and enhancement, the major system features are working well. The current prototype meets the user's needs, has been in routine sine August 1984, and has resulted in a doubling of the analyst's throughput on this test.

For prototyping to be practical in a real time data acquisition environment, it is necessary to have versatile development tools. Forth provides this environment.

What's Wrong with Forth?

John S. James
Abstract

Forth offers unusual control over the entire hardware and software environment, allowing design efficiencies far more important than its speed and memory performance. But some traditional coding practices have used this flexibility in ways which impede the development and maintenance of large software projects. And easy access to system facilities has too often allowed vendors to get away without providing complete application support for any particular purpose.

The keys to improvement are modular software design, information hiding, and closure. We will have succeeded when programmers can join a project, then quickly come up to speed and contribute within a single section of a complex system.

Meta-Compilation System

Rieks Joosten
Abstract Only

An overview is given of concerns and techniques leading to the creation of a generalized meta-Forth system. Analysis shows that the meta process can best be controlled by a number of states in distinct environments. An integrated administration tool adds to the flexibility of the system.

Some Problems in Implementations of the Forth Stnadards

Mahlon G. Kelly and Nicholas Spies
Abstract

There have been many complaints about the Forth standards. These have been both from users and from those responsible for implementing the standards in commercial Forths. Complaints have even appeared in letters in major magazines, and have included such adjectives as "unusable". But the reasons for the complaints have been, in large part, unfocused. Many users' complaints seem to stem from a wish that standard Forth "did more", which reveals a misunderstanding of the purpose of the standards: to provide a minimal word set so as to allow writing of portable code (although one may argue what "minimal" means -- for example standard floating-point words were called for even before Forth-79 was formulated). Perhaps a more basic user's complaint is that small changes in Forth-83 (e.g. redefinition of ' and the termination of LOOP ) make it difficult to translate code and can lead to subtle bugs (e.g. with floored division) if the differences are not understood. The failure of the Forth-83 standard document to explicitly spell out differences aggravates this problem.

A Tokenized Rule Processing System

Steven M. Lewis and Mike Fisher
Abstract Only

In examining rule processing in LISP we were struck with the crudeness with which text was treated. We have developed a rule processor in Forth in which the rules are strings of Forth words. Undefined words are automatically entered into a text vocabulary. As unknown words are entered into the vocabulary they are tested for the presence of special characters and English constructs such as ending with s. Words with appropriate construction are designated as one of 255 special classes. Clauses are compared on a word by word basis, each word being tested not only for equality but for synonyms. The processor will automatically equate regular plural and singular words and expand regular possessive forms. Special words allow rules to remember indeterminate antecedents and retain them during the testing of a rule. Articles and similar words are included in the clauses but not tested in matching clauses. Incorporating the syntactic processor into an available inference machine (Park, Mountain View Press) gives a flexible powerful knowledge system.

Concrete Suggestions for a Forth Floating-Point Stnadard

Ferren MacIntyre
Abstract Only

Many serious programmers dismiss Forth as unsuitable for professional work because it lacks standard floating-point (FP) Capability. Proposed here is a word set based upon two years of intensive use of the MMSForth words (including FQUANs and "long-addressed" variants) with the 8087 numerical coprocessor, with input from several other approaches.

Most operations are the familiar Forth words preceded by an F, or a C for complex arithmetic. Short words are strongly preferred because of the natural length of FP definitions. Unusual words include -F for negation; -F- and F\ for FSWAP F- and FSWAP F/, which are single instructions on the 8087; and FRT2 for FROT FROT, symmetrical with FROT and used about as often.

Left open is the choice of FP number indication: a European-style comma, as 123, or 123,4 (which might be confused with the compiling comma); or an embedded period, as 123.0 (which requires that double-length numbers end with a period, as 123.).

A carefully designed FRAND random-number generator is needed. For compatibility, software-FP packages require an 8-deep FP stack. Index registers seem desirable for array manipulations several words deep from a calling loop.

Plotter Drivers as an Exercise in Forth Wordset Design

A. Richard Miller and Thomas B. Dowling
Abstract Only

Three levels of driver design are discussed for a typical X-Y plotter. A minimum driver merely permits Forth to mimic the plotter's internal BASIC command set. A more elegant one transforms the same commands into a more Forth-like and more English-like wordset. Finally, the command set is modified and vectored into the existing MMSForth TGRAPH (Turtle Graphics) utility. This transforms the plotter into an optional video screen to which one can output TGRAPH graphics routines without any modification.

Demonstrations will be given using the inexpensive Radio Shack FP-215 Flatbed Plotter. Source code for a simple Forth implementation is included, and can be adapted to many similar plotters.

Editors and Editing Technique: A Review of Fancy and Practical Features in the Evolution of the MMSForth Screen Editor

Jill Miller and A. Richard Miller
Abstract Only

The editor is the ultimate utility for the Forth programmer, as it is the one with which he or she works most completely. And since it is apt to be written in Forth, it is easily adapted to new ideas. Thus the important and malleable Forth editor receives great attention and is a logical focus for objective and subjective design considerations.

Since 1978, MMSForth Editor has evolved through many standard and special versions. Some of the more interesting features and user techniques, from our earliest line editor through the sophisticated screen editor in our new MMSForth V2.4, are discussed.

Forth in the Computer Numerical Control Environment

John Mullen
Abstract Only

In order to help students grasp the concepts of computer-aided manufacture, a small Computer Numerical Control (CNC) workstation was built. It consists of a microcomputer, a vertical mill, a plotter, a printer and necessary interface electronics. The workstation may be controlled by means of either a Forth-based control language or a CNC language closely following the standards of EIA RS-358-B.

Although the capacity of the mill is small and the resolution of the system is not consistent with industry standards, the workstation provides students with the desired experiences and also serves as a physical demonstration of the potential of Forth.

The development of this workstation was greatly facilitated by the use of Forth, Forth-79 was used to test electronic driver and interface circuits, control the plotter and mill, from a basis for the Forth-like control language, and implemented the EIA standard CNC language. In addition, since the CNC languages are imbedded in Forth, the support features of the Forth system are available to the user.

The inherent transportability of Forth together with a hierarchial modular design result in an implementation this is almost totally hardware independent and very flexible. As a result, this project serves as an extensive demonstration of the utility of the integrated Forth environment in CNC applications.

Under the Hood of a Superchip: The NOVIX Forth Engine

Charles H. Moore and Robert W. Murphy
Abstract

The NC4000P is a single chip Forth Engine based upon minimum hardware concepts developed by Mr. Charles H. Moore. This highly parallel machine architecture directly executes Forth primitives in a single clock cycle. The initial implementation of this device is based upon a 4000 gate CMOS semi-custom integrated circuit operating at an 9 MHz clock rate.

Forth for a Multimicroprocessor Control System

C. A. Myerholtz, A. J. Schubert, M. J. Kristo and C.G. Enke
Abstract

In our laboratory, a triple quadruple mass spectrometer (TQMS) has been placed under complete computer control. A distributed processing system of several microcomputers were required to control the more than 30 instrumental parameters, acquire data and perform peak finding in real time. The software for this system was based on a standard Forth operating system.

A Versatile Software Control System for a Triple Quadrupole Mass Spectrometer

C. A. Myerholtz, A. J. Schubert, M. J. Kristo and C.G. Enke
Abstract

The complete computerization of a triple quadruple mass spectrometer (TQMS) in our laboratory has been accomplished by a software control system that allows the operator to conveniently and flexibly control the instrument's 30 parameters and 5 different scan modes. Forth has allowed us to create such a system by allowing the system programmers to tailor-make a command syntax specific to our application, while still allowing access to the Forth kernel and application primitives.

Basic on Forth

Hans Nieuwenhuüzen and Harm Bramms
Abstract Only

Design is discussed of an implementation of the BASIC language on Forth. The program is changed to one long Forth executable statement. The data is separate from the program.

Implementing Forth for the Multics Operating System

Michael A. Pandolf
Abstract

Like many tools and subsystems on Multics, Forth resulted from a wish of one of its users (in this instance one of its developers) to add to Multics's range of computation. After a period of development and some local exposure, such spontaneously generated software enters a stage of peer review and wider exposure that enables it to be considered for product review. Currently, a version of Forth that follows the design as described in the "fig-Forth Installation Manual" by the Forth Interest Group is in the local exposure state at MDC/CISL and is not yet scheduled for peer or product review.

A Process Monitor

Hemant S. Patel
Abstract Only

This paper discusses a Forth implementation for monitoring, control and optimization of a medium-sized chemical process. The 68000 based program checks and stores data on a hard disk for future retrieval in graphic or tabular form. Routines for lab analysis and product quality management via CUSUM technique are provided. Both field and lab data are used to optimize conversions and yields. To quickly isolate and respond to plant upsets, field variables are organized and displayed as trend charts in groups containing up to eight variables. A top-down tree structure is used so that each variable in a group above is casually related to another group below. Forth screens are utilized as fill-in shells for customer reports and help files.

Time critical modules are written in assembler. Two byte integer format is used for mass storage with four byte integer arithmetic used for computational accuracy. The resultant package is extremely fast and allows features such as scrolling of trend charts. While non-Forth commercial programs offer a wide range of features, all of them are hardware specific, with customizing being difficult and laborious. Because of Forth's transportability, adaptations to other computers are relatively easy. Furthermore, Forth's modularity makes customizing and add-on's quit simple.

Object Oriented Extensions to Forth

Richard Pountain
Abstract Only

The paper will describe two iterations in the evolution of a set of object oriented extensions to Forth-79, based loosely on the syntax and semantics of Smalltalk-80. The initial inspiration for the project was a desire to create a structured data facility in Forth, equivalent to records in Pascal (as an illustration for a book chapter on Data Structures in Forth).

The initial idea was to use the existing CREATE ... DOES> mechanism for this purpose. This end was easily achieved by writing a defining word which produces "smart" identifiers with which to address the fields of a record. Having accomplished this, the author noticed that in fact CREATE ... DOES> contains the seeds of a far more powerful data abstraction mechanism, namely classes as in Simula or Smalltalk. It is equivalent to a class constructor without any inheritance mechanism.

State Sequence Handlers

Edward B. Rawson
Abstract Only

We describe a new type of sequence control structure which allows an ordinary : word to behave as a small state machine. The control structures may be freely mixed with BEGIN, UNTIL, etc., and with IF, ELSE, and THEN, with conventional nesting restrictions. The new structures include analogs of BEGIN, UNTIL, etc., as well as several other words which support terse, readable, state machine code.

The normal state variable is replaced by an entry pointer, but its handling is largely hidden in the source code, and application code never need supply a pointer value. Definition may be understood as standard Forth procedures, with the understanding that execution may ``hand up'' in one of the internal loops or called procedures until it is proper to proceed. Repeated calls to the main procedure result in repeated execution of the loop code or the called procedure until continuation is appropriate.

The sequence control structures encourage structured code, make state entry and exit natural, and produce fast, compact, object code. They eliminate the need to assign and manage state numbers. The structures and several application are described.

From Bubble to Quick: A Forth Comparison of Sorting Algorithms

John Rible
Abstract Only

This paper compares generalized implementation of half a dozen sort algorithms in Forth.

Examples of sorting integers and strings are used to illustrate the different methods. Even the faster sorts are coded compactly in Forth.

The sorting algorithms take item numbers as arguments, allowing users to define their own EXCHANGE and COMPARE words. Informal guidelines are given for choosing an appropriate algorithm for your application.

Combining Forth and the Rest of the Computer World: Dynamic Loading of Subroutines Written in Other Languages and Their Use as Forth Words

William L. Sebok
Abstract

Dynamic subroutine loading has been added to the local VAX implementation of Forth-79 that runs under the Berkeley dialect of Unix (so called "Princeton Forth"). This paper is about the semantics of how this might be specified and a sketch of how it was implemented here. Also mentioned are some of the problems that must be faced.

The Need for a Standard Test-Suite

Nicholas Spies and Mahlon G. Kelly
Abstract

A test suite is a set of programs used to assure that a compiler or programming language meets explicit specifications. A standard Forth test suite would bring many advantages to the Forth community. Ambiguities in the language of the standard would be resolved through example. Both users and system-authors would have a convenient way to confirm that their dialects meet standard requirements. And most importantly, dialects that could run the standard test suite successfully would be virtually assured of being code-compatible. In short, we feel that a standard test suite is a necessary step in the evolution of an effective Forth standard.

Forth in a Muon Channel with CAMAC Control

Robbie Spruit
Abstract Only

Control and diagnostic software was developed for M15, a recently commissioned surface muon channel at TriumF. Logistics gave rise to several efforts in several programming languages. This paper describes the Forth diagnostic package, and the choices of languages is briefly discussed. Several extensions to the Forth language, and the way they were put to use, are shown in the framework of a detailed account of the software implementation. The emphasis is on the production of readable code and on the design of constructs that most closely model the structure of the application.

NAPLPS Decoding in Forth

Billie Goldstein Stevens
Abstract

The North American Presentation Level Protocol Syntax (NAPLPS) is a standard for encoding both textual and graphic information for videotex. Given a personal computer with hardware (either built in or added on) that can produce a display conforming to the standard, the actual decoding of NAPLPS-encoded data can be done in software. Such software decoders have been written both experimentally and as commercial products (primarily in Canada, where consumer videotex is more prevalent than in the U.S.). NAPLPS decoding is similar to recursive descent parsing, but NAPLPS code does not always have the clean structure of a context-free language. There are awkward jumps and unexpected escapes possible. Forth leads itself readily to the task of NAPLPS decoding, gracefully handling both the straightforward parsing and the sudden shifts. An experimental NAPLPS decoder in Forth has been developed at the CBS Technology Center. We briefly describe the NAPLPS coding techniques, then explain the design and implementation of the decoder. The suitability of Forth for this task is illustrated and emphasized.

Controlling an Integrated Automatic Parameter Characterization System with Forth

Jonathan Sun and Barry Mason
Abstract

An integrated automatic parametric characterization system for semiconductors has been developed in GTE Communication Systems. The system consists of an automatic testing and measuring system, a database, and extraction algorithms for device parameter. This paper describes an automated system that fulfills these modeling tasks for existent and future technologies. The architecture of this system, the operation of the software, and a brief description of design methodology based upon Forth and the tradeoffs between Forth and BASIC for this application are discussed.

REvised REcursive AND? 'REPTIL :IS

Israel Urieli
Abstract

Forth, described by some as the "hackers' language", is having a hard time being accepted within the computing community ranging from schoolchildren through computer scientists. Schools and colleges which are happily teaching BASIC, LOGO and Pascal, are not even considering Forth as an alternative. Probably the major reason for this is the singular lack of readability of Forth, demanding a strict self-discipline form the programmer with regard to style, documentation and structure. Many have address the question of readability, and have suggested that the major culprits include the cryptic symbology, the strange structured constructs and the lack of local parameters requiring an excessive dependence on stack operations. There have been many attempts to eliminate these problems, however, most of these have been in terms of extensions to the existing Forth kernel, rather than an appraisal of the language and some restructuring.

REPTIL represents and attempt to present a Forth-like language as a viable pedagogically sound, alternative language for student programming at all levels. Since its initial presentation in 1984 it has been totally revised and is currently being rewritten. This paper is a review of the infrastructure and some of the structured features of REPTIL.

Forth-79 Profiled

Alan J. Winfiled, Ron Goodman and Richard Pountain
Abstract Only

The technique of `profiling' an applications program, that is obtaining statistical data on the length of time that the program spends in each of its component sections, is well known and allow times critical parts to be identified and thus optimzied.

Less obvious is the possibility that an entire operating system might be profiled. This is hardly practical with the majority of operating system (even less, compiler), but the simplicity and virtual machine concept of a Forth system does lend itself to the in-depth analysis that profiling will allow.

This paper describes such an analysis for a 79-standard Forth system. Results are summarized which detail from high-level words through to the simplest code primitives, including NEXT}, a number of different activities of the system. In particular, interpreting, and compiling are profiled.

Finally, an analysis which combines the separate results is given showing the overall average activity of the Forth system. Some surprising results are indicated; in particular the amount of time that the system spends in the inner interpreter. Also a number of code primitives turn out to be executed unexpectedly often, while others are executed much less frequently than might be expected.

These results have proved to be particularly useful in our quest for a Forth machine architecture, by indicating precisely which aspects of the hardware design need to be given special attention.

Production Testing of Domestic Clothes Dryers Using LMS Forth

J. Dermod Wood
Abstract

This paper describes the implementation of a semi-automated testing facility for domestic clothes dryers, with particular emphasis on the system functionality, and the approach taken for controlling asynchronous concurrent tasks.

Working Group Reports

Artificial Intelligence

William Dress and Ray Adams

Data Acquistions and Real-Time Systems

Carol Pruitt and Wing Ng

Forth Machines

Alan Winfield and Robert Dixon

Forth and Unix

Mitch Bradley
Abstract

The Forth and Unix working group included a number of people who are currently using Forth with the UNIX operating system, and a few interested observers. The group agreed on a set of guidelines for the interface between Forth and UNIX, based on the experience of the participants. Adoption of these guidelines should increase the ability of Forth users under UNIX to share code.

Graphics

Leonard Zettel

Robotics

Alan Furman

Standardization

Mahlon Kelly, Nick Spies and Ferren MacIntyre

State Machines

Randy Dumse

Teleconferencing About Forth

John James

8086 Limitations

Tony Hart