\annex{Perspective} % C (informative annex) \label{annex:intro} \setwordlist{core} The purpose of this section is to provide an informal overview of Forth as a language, illustrating its history, most prominent features, usage, and common implementation techniques. Nothing in this section should be considered as binding upon either implementors or users. A list of books and articles is given in Annex \ref{annex:bib} for those interested in learning more about Forth. \section{Features of Forth} % C.1 Forth provides an interactive programming environment. Its primary uses have been in scientific and industrial applications such as instrumentation, robotics, process control, graphics and image processing, artificial intelligence and business applications. The principal advantages of Forth include rapid, interactive software development and efficient use of computer hardware. Forth is often spoken of as a language because that is its most visible aspect. But in fact, Forth is both more and less than a conventional programming language: more in that all the capabilities normally associated with a large portfolio of separate programs (compilers, editors, etc.) are included within its range and less in that it lacks (deliberately) the complex syntax characteristic of most high-level languages. The original implementations of Forth were stand-alone systems that included functions normally performed by separate operating systems, editors, compilers, assemblers, debuggers and other utilities. A single simple, consistent set of rules governed this entire range of capabilities. Today, although very fast stand-alone versions are still marketed for many processors, there are also many versions that run co-resident with conventional operating systems such as MS-DOS and UNIX. Forth is not derived from any other language. As a result, its appearance and internal characteristics may seem unfamiliar to new users. But Forth's simplicity, extreme modularity, and interactive nature offset the initial strangeness, making it easy to learn and use. A new Forth programmer must invest some time mastering its large command repertoire. After a month or so of full-time use of Forth, that programmer could understand more of its internal working than is possible with conventional operating systems and compilers. The most unconventional feature of Forth is its \emph{extensibility}. The programming process in Forth consists of defining new ``words''. actually new commands in the language. These may be defined in terms of previously defined words, much as one teaches a child concepts by explaining them in terms of previously understood concepts. Such words are called ``high-level definitions''. Alternatively, new words may also be defined in assembly code, since most Forth implementations include an assembler for the host processor. This extensibility facilitates the development of special application languages for particular problem areas or disciplines. Forth's extensibility goes beyond just adding new commands to the language. With equivalent ease, one can also add new \emph{kinds} of words. That is, one may create a word which itself will define words. In creating such a defining word the programmer may specify a specialized behavior for the words it will create which will be effective at compile-time, at run-time, or both. This capability allows one to define specialized data types, with complete control over both structure and behavior. Since the run-time behavior of such words may be defined either in high-level or in code, the words created by this new defining word are equivalent to all other kinds of Forth words in performance. Moreover, it is even easy to add new \emph{compiler directives} to implement special kinds of loops or other control structures. Most professional implementations of Forth are written in Forth. Many Forth systems include a ``meta-compiler'' which allows the user to modify the internal structure of the Forth system itself. \section{History of Forth} % C.2 Forth was invented by Charles H. Moore. A direct outgrowth of Moore's work in the 1960's, the first program to be called Forth was written in about 1970. The first complete implementation was used in 1971 at the National Radio Astronomy Observatory's 11-meter radio telescope in Arizona. This system was responsible for pointing and tracking the telescope, collecting data and recording it on magnetic tape, and supporting an interactive graphics terminal on which an astronomer could analyze previously recorded data. The multi-tasking nature of the system allowed all these functions to be performed concurrently, without timing conflicts or other interference --- a very advanced concept for that time. The system was so useful that astronomers from all over the world began asking for copies. Its use spread rapidly, and in 1976 Forth was adopted as a standard language by the International Astronomical Union. In 1973, Moore and colleagues formed FORTH, Inc. to explore commercial uses of the language. FORTH, Inc. developed multi-user versions of Forth on minicomputers for diverse projects ranging from data bases to scientific applications such as image processing. In 1977, FORTH, Inc. developed a version for the newly introduced 8-bit microprocessors called ``microFORTH'', which was successfully used in embedded microprocessor applications in the United States, Britain and Japan. Stimulated by the volume marketing of microFORTH, a group of computer hobbyists in Northern Cal\-i\-for\-nia became interested in Forth, and in 1978 formed the Forth Interest Group (FIG). They developed a simplified model which they implemented on several microprocessors and published listings and disks at very low cost. Interest in Forth spread rapidly, and today there are chapters of the Forth Interest Group throughout the U.S. and in over fifteen countries. By 1980, a number of new Forth vendors had entered the market with versions of Forth based upon the FIG model. Primarily designed for personal computers, these relatively inexpensive Forth systems have been distributed very widely. \section{Hardware implementations of Forth} % C.3 The internal architecture of Forth simulates a computer with two stacks, a set of registers, and other standardized features. As a result, it was almost inevitable that someone would attempt to build a hardware representation of an actual Forth computer. In the early 1980's, Rockwell produced a 6502-variant with Forth primitives in on-board ROM, the \linebreak Rockwell 65F11. This chip has been used successfully in many embedded microprocessor applications. In the mid-1980's Zilog developed the z8800 (Super8) which offered ENTER (nest), EXIT (unnest) and NEXT in microcode. In 1981, Moore undertook to design a chip-level implementation of the Forth virtual machine. Working first at FORTH, Inc. and subsequently with the start-up company NOVIX, formed to develop the chip, Moore completed the design in 1984, and the first prototypes were produced in early 1985. More recently, Forth processors have been developed by Harris Semiconductor Corp., Johns Hopkins University, and others. \section{Standardization efforts} % C.4 The first major effort to standardize Forth was a meeting in Utrecht in 1977. The attendees produced a preliminary standard, and agreed to meet the following year. The 1978 meeting was also attended by members of the newly formed Forth Interest Group. In 1979 and 1980 a series of meetings attended by both users and vendors produced a more comprehensive standard called Forth 79. Although Forth 79 was very influential, many Forth users and vendors found serious flaws in it, and in 1983 a new standard called Forth 83 was released. Encouraged by the widespread acceptance of Forth 83, a group of users and vendors met in 1986 to investigate the feasibility of an American National Standard. The X3J14 Technical Committee for ANS Forth held its first meeting in 1987. This Standard is the result. \section{Programming in Forth} % C.5 Forth is an English-like language whose elements (called ``words'') are named data items, procedures, and defining words capable of creating data items with customized characteristics. Procedures and defining words may be defined in terms of previously defined words or in machine code, using an embedded assembler. Forth ``words'' are functionally analogous to subroutines in other languages. They are also equivalent to commands in other languages --- Forth blurs the distinction between linguistic elements and functional elements. Words are referred to either from the keyboard or in program source by name. As a result, the term ``word'' is applied both to program (and linguistic) units and to their text names. In parsing text, Forth considers a word to be any string of characters bounded by spaces. There are a few special characters that cannot be included in a word or start a word: space (the universal delimiter), CR (which ends terminal input), and backspace or DEL (for backspacing during keyboard input). Many groups adopt naming conventions to improve readability. Words encountered in text fall into three categories: defined words (i.e., Forth routines), numbers, and undefined words. For example, here are four words: \begin{quote}\ttfamily \word{HERE} \quad \word{DOES} \quad \word{!} \quad 8493 \end{quote} The first three are standard-defined words. This means that they have entries in Forth's dictionary, described below, explaining what Forth is to do when these words are encountered. The number ``8493'' will presumably not be found in the dictionary, and Forth will convert it to binary and place it on its push-down stack for parameters. When Forth encounters an undefined word and cannot convert it to a number, the word is returned to the user with an exception message. Architecturally, Forth words adhere strictly to the principles of ``structured programming'': \begin{itemize} \item Words must be defined before they are used. \item Logical flow is restricted to sequential, conditional, and iterative patterns. Words are included to implement the most useful program control structures. \item The programmer works with many small, independent modules (words) for maximum testability and reliability. \end{itemize} Forth is characterized by five major elements: a dictionary, two push-down stacks, interpreters, an as\-sem\-bler, and virtual storage. Although each of these may be found in other systems, the combination produces a synergy that yields a powerful and flexible system. \subsection{The Forth dictionary} % C.5.1 A Forth program is organized into a dictionary that occupies most of the memory used by the system. This dictionary is a threaded list of variable-length items, each of which defines a word. The content of each definition depends upon the type of word (data item, constant, sequence of operations, etc.). The dictionary is extensible, usually growing toward high memory. On some multi-user systems individual users have private dictionaries, each of which is connected to a shared system dictionary. Words are added to the dictionary by ``defining words'', of which the most commonly used is \word{:} (colon). When \word{:} is executed, it constructs a definition for the word that follows it. In classical implementations\footnote{% Other common implementation techniques include direct translation to code and other types of tokens. }, the content of this definition is a string of addresses of previously defined words which will be executed in turn whenever the word being defined is invoked. The definition is terminated by \word{;} (semicolon). For example, here is a definition: \begin{quote}\ttfamily \word{:} RECEIVE \word{p} -{}- addr n ) \word{PAD} \word{DUP} 32 \word{ACCEPT} \word{;} \end{quote} The name of the new word is \texttt{RECEIVE}. The comment (in parentheses) indicates that it requires no parameters and will return an address and count on the data stack. When \texttt{RECEIVE} is executed, it will perform the words in the remainder of the definition in sequence. The word \word{PAD} places on the stack the address of a scratch pad used to handle strings. \word{DUP} duplicates the top stack item, so we now have two copies of the address. The number \texttt{32} is also placed on the stack. The word \word{ACCEPT} takes an address (provided by \word{PAD}) and length (32) on the stack, accepts from the keyboard a string of up to 32 characters which will be placed at the specified address, and returns the number of characters received. The copy of the scratch-pad address remains on the stack below the count so that the routine that called \texttt{RECEIVE} can use it to pick up the received string. \subsection{Push-down stacks} % C.5.2 The example above illustrates the use of push-down stacks for passing parameters between Forth words. Forth maintains two push-down stacks, or LIFO lists. These provide communication between Forth words plus an efficient mechanism for controlling logical flow. A stack contains 16-bit items on 8-bit and 16-bit computers, and 32-bit items on 32-bit processors. Double-cell numbers occupy two stack positions, with the most-significant part on top. Items on either stack may be addresses or data items of various kinds. Stacks are of indefinite size, and usually grow towards low memory. Although the structure of both stacks is the same, they have very different uses. The user interacts most directly with the Data Stack, which contains arguments passed between words. This function replaces the calling sequences used by conventional languages. It is efficient internally, and makes routines intrinsically re-entrant. The second stack is called the Return Stack, as its main function is to hold return addresses for nested definitions, although other kinds of data are sometimes kept there temporarily. The use of the Data Stack (often called just ``the stack'') leads to a notation in which operands precede operators. The word \word{ACCEPT} in the example above took an address and count from the stack and left another address there. Similarly, a word called \word[string]{BLANK} expects an address and count, and will place the specified number of space characters (20H) in the region starting at that address. Thus, \begin{quote}\ttfamily \word{PAD} 25 \word[string]{BLANK} \end{quote} will fill the scratch region whose address is pushed on the stack by \word{PAD} with 25 spaces. Application words are usually defined to work similarly. For example, \begin{quote}\ttfamily 100 SAMPLES \end{quote} might be defined to record 100 measurements in a data array. Arithmetic operators also expect values and leave results on the stack. For example, \word{+} adds the top two numbers on the stack, replacing them both by their sum. Since results of operations are left on the stack, operations may be strung together without a need to define variables to use for temporary storage. \subsection{Interpreters} % C.5.3 Forth is traditionally an interpretive system, in that program execution is controlled by data items rather than machine code. Interpreters can be slow, but Forth maintains the high speed required of real-time applications by having two levels of interpretation. The first is the text interpreter, which parses strings from the terminal or mass storage and looks each word up in the dictionary. When a word is found it is executed by invoking the second level, the address interpreter. The second is an ``address interpreter'' Although not all Forth systems are implemented in this way, it was the first and is still the primary implementation technology. For a small cost in performance, an address interpreter can yield a very compact object program, which has been a major factor in Forth's wide acceptance in embedded systems and other applications where small object size is desirable. The address interpreter processes strings of addresses or tokens compiled in definitions created by \word{:} (colon), by executing the definition pointed to by each. The content of most definitions is a sequence of addresses of previously defined words, which will be executed by the address interpreter in turn. Thus, when the word \texttt{RECEIVE} (defined above) is executed, the word \word{PAD}, the word \word{DUP}, the literal 32, and the word \word{ACCEPT} will be executed in sequence. The process is terminated by the semicolon. This execution requires no dictionary searches, parsing, or other logic, because when \texttt{RECEIVE} was \emph{compiled} the dictionary was searched for each word, and its address (or other token) was placed in the next successive cell of the entry. The text was not stored in memory, not even in condensed form. The address interpreter has two important properties. First, it is fast. Although the actual speed depends upon the specific implementation, professional implementations are highly optimized, often requiring only one or two machine instructions per address. On most benchmarks, a good Forth implementation substantially out-performs interpretive languages such as BASIC or LISP, and will compare favorably with other compiled high-level languages. Second, the address interpreter makes Forth definitions extremely compact, as each reference requires only one cell. In comparison, a subroutine call constructed by most compilers involves instructions for handling the calling sequence (unnecessary in Forth because of the stack) before and after a CALL or JSR instruction and address. Most of the words in a Forth dictionary will be defined by \word{:} (colon) and interpreted by the address interpreter. Most of Forth itself is defined this way. \subsection{Assembler} % C.5.4 Most implementations of Forth include a macro assembler for the CPU on which they run. By using the defining word \word[tools]{CODE} the programmer can create a definition whose behavior will consist of executing actual machine instructions. \word[tools]{CODE} definitions may be used to do I/O, implement arithmetic primitives, and do other machine-dependent or time-critical processing. When using \word[tools]{CODE} the programmer has full control over the CPU, as with any other assembler, and \word[tools]{CODE} definitions run at full machine speed. This is an important feature of Forth. It permits explicit computer-dependent code in manageable pieces with specific interfacing conventions that are machine-independent. To move an application to a different processor requires re-coding only the \word[tools]{CODE} words, which will interact with other Forth words in exactly the same manner. Forth assemblers are so compact (typically a few Kbytes) that they can be resident in the system (as are the compiler, editor, and other programming tools). This means that the programmer can type in short \word[tools]{CODE} definitions and execute them immediately. This capability is especially valuable in testing custom hardware. \subsection{Virtual memory} % C.5.5 The final unique element of Forth is its way of using disk or other mass storage as a form of ``virtual memory'' for data and program source. As in the case of the address interpreter, this approach is historically characteristic of Forth, but is by no means universal. Disk is divided into 1024-byte blocks. Two or more buffers are provided in memory, into which blocks are read automatically when referred to. Each block has a fixed block number, which in native systems is a direct function of its physical location. If a block is changed in memory, it will be automatically written out when its buffer must be reused. Explicit reads and writes are not needed; the program will find the data in memory whenever it accesses it. Block-oriented disk handling is efficient and easy for native Forth systems to implement. As a result, blocks provide a completely transportable mechanism for handling program source and data across both native and co-resident versions of Forth on different host operating systems. Definitions in program source blocks are compiled into memory by the word \word[block]{LOAD}. Most implementations include an editor, which formats a block for display into 16 lines of 64 characters each, and provides commands modifying the source. An example of a Forth source block is given in Fig. \ref{fig:block} below. Source blocks have historically been an important element in Forth style. Just as Forth definitions may be considered the linguistic equivalent of sentences in natural languages, a block is analogous to a paragraph. A block normally contains definitions related to a common theme, such as ``vector arithmetic''. A comment on the top line of the block identifies this theme. An application may selectively load the blocks it needs. Blocks are also used to store data. Small records can be combined into a block, or large records spread over several blocks. The programmer may allocate blocks in whatever way suits the application, and on native systems can increase performance by organizing data to minimize disk head motion. Several Forth vendors have developed sophisticated file and data base systems based on Forth blocks. Versions of Forth that run co-resident with a host OS often implement blocks in host OS files. Others use the host files exclusively. The Standard requires that blocks be available on systems providing any disk access method, as they are the only means of referencing disk that can be transportable across both native and co-resident implementations. \subsection{Programming environment} % C.5.6 Although this Standard does not require it, most Forth systems include a resident editor. This enables a programmer to edit source and recompile it into executable form without leaving the Forth environment. As it is easy to organize an application into layers, it is often possible to recompile only the topmost layer (which is usually the one currently under development), a process which rarely takes more than a few seconds. Most Forth systems also provide resident interactive debugging aids, not only including words such as those in \xref[15. The optional Programming-Tools word set]{wordlist:tools}, but also having the ability to examine and change the contents of \word{VARIABLE}s and other data items and to execute from the keyboard most of the component words in both the underlying Forth system and the application under development. The combination of resident editor, integrated debugging tools, and direct executability of most defined words leads to a very interactive programming style, which has been shown to shorten development time. \subsection{Advanced programming features} % C.5.7 One of the unusual characteristics of Forth is that the words the programmer defines in building an application become integral elements of the language itself, adding more and more powerful application-oriented features. For example, Forth includes the words \word{VARIABLE} and \word[double]{2VARIABLE} to name locations in which data may be stored, as well as \word{CONSTANT} and \word[double]{2CONSTANT} to name single and double-cell values. Suppose a programmer finds that an application needs arrays that would be automatically indexed through a number of two-cell items. Such an array might be called \texttt{2ARRAY}. The prefix ``2'' in the name indicates that each element in this array will occupy two cells (as would the contents of a \word[double]{2VARIABLE} or \word[double]{2CONSTANT}). The prefix ``2'', however, has significance only to a human and is no more significant to the text interpreter than any other character that may be used in a definition name. Such a definition has two parts, as there are two ``behaviors'' associated with this new word \texttt{2ARRAY}, one at compile-time, and one at run or execute time. These are best understood if we look at how \texttt{2ARRAY} is used to define its arrays, and then how the array might be used in an application. In fact, this is how one would design and implement this word. Beginning the top-down design process, here's how we would like to use \texttt{2ARRAY}: \begin{quote}\ttfamily 100 2ARRAY RAW \quad 50 2ARRAY REFINED \end{quote} In the first case, we are defining an array 100 elements long, whose name is \texttt{RAW}. In the second, the array is 50 elements long, and is named \texttt{REFINED}. In each case, a size parameter is supplied to \texttt{2ARRAY} on the data stack (Forth's text interpreter automatically puts numbers there when it encounters them), and the name of the word immediately follows. This order is typical of Forth defining words. When we use \texttt{RAW} or \texttt{REFINED}, we would like to supply on the stack the index of the element we want, and get back the address of that element on the stack. Such a reference would characteristically take place in a loop. Here's a representative loop that accepts a two-cell value from a hypothetical application word \texttt{DATA} and stores it in the next element of \texttt{RAW}: \begin{quote}\ttfamily \word{:} ACQUIRE 100 0 \word{DO} DATA \word{I} RAW \word{2!} \word{LOOP} \word{;} \end{quote} The name of this definition is \texttt{ACQUIRE}. The loop begins with \word{DO}, ends with \word{LOOP}, and will execute with index values running from 0 through 99. Within the loop, \texttt{DATA} gets a value. The word \word{I} returns the current value of the loop index, which is the argument to RAW. The address of the selected element, returned by \texttt{RAW}, and the value, which has remained on the stack since \texttt{DATA}, are passed to the word \word{2!} (pronounced ``two-store''), which stores two stack items in the address. Now that we have specified exactly what \texttt{2ARRAY} does and how the words it defines are to behave, we are ready to write the two parts of its definition: \begin{quote}\ttfamily \word{:} 2ARRAY~~\word{p} n -{}- ) \\ \tab \word{CREATE} ~ \word{2*} \word{CELLS} \word{ALLOT} \\ \tab \word{DOES} ~~ \word{p} i a -{}- a') ~ \word{SWAP} ~ \word{2*} \word{CELLS} \word{+} ~ \word{;} \end{quote} The part of the definition before the word \word{DOES} specifies the ``compile-time'' behavior, that is, what the \texttt{2ARRAY} will do when it us used to define a word such as \texttt{RAW}. The comment indicates that this part expects a number on the stack, which is the size parameter. The word \word{CREATE} constructs the definition for the new word. The phrase \word{2*} \word{CELLS} converts the size parameter from two-cell units to the internal addressing units of the system (normally characters). \word{ALLOT} then allocates the specified amount of memory to contain the data to be associated with the newly defined array. The second line defines the ``run-time'' behavior that will be shared by all words defined by \texttt{2ARRAY}, such as \texttt{RAW} and \texttt{REFINED}. The word \word{DOES} terminates the first part of the definition and begins the second part. A second comment here indicates that this code expects an index and an address on the stack, and will return a different address. The index is supplied on the stack by the caller (of \texttt{RAW} in the example), while the address of the content of a word defined in this way (the \word{ALLOT}ted region) is automatically pushed on top of the stack before this section of the code is to be executed. This code works as follows: \word{SWAP} reverses the order of the two stack items, to get the index on top. \word{2*} \word{CELLS} converts the index to the internal addressing units as in the compile-time section, to yield an offset from the beginning of the array. The word \word{+} then adds the offset to the address of the start of the array to give the effective address, which is the desired result. Given this basic definition, one could easily modify it to do more sophisticated things. For example, the compile-time code could be changed to initialize the array to zeros, spaces, or any other desired initial value. The size of the array could be compiled at its beginning, so that the run-time code could compare the index against it to ensure it is within range, or the entire array could be made to reside on disk instead of main memory. \emph{None of these changes would affect the run-time usage we have specified in any way}. This illustrates a little of the flexibility available with these defining words. \subsection{A programming example} % C.5.8 Figure \ref{fig:block} contains a typical block of Forth source. It represents a portion of an application that controls a bank of eight LEDs used as indicator lamps on an instrument, and indicates some of the ways in which Forth definitions of various kinds combine in an application environment. This example was coded for a STD-bus system with an 8088 processor and a millisecond clock, which is also used in the example. The LEDs are interfaced through a single 8-bit port whose address is 40H. This location is defined as a \word{CONSTANT} on Line 1, so that it may be referred to by name; should the address change, one need only adjust the value of this constant. The word \texttt{LIGHTS} returns this address on the stack. The definition \texttt{LIGHT} takes a value on the stack and sends it to the device. The nature of this value is a bit mask, whose bits correspond directly to the individual lights. Thus, the command \texttt{255 LIGHT} will turn on all lights, while \texttt{0 LIGHT} will turn them all off. \begin{figure} \begin{center} \ttfamily \begin{tabular}{|rp{32em}|} \hline \multicolumn{2}{|l|}{Block 180} \\ 0. & \word{p} LED control )\\ 1. & \word{HEX} 40 \word{CONSTANT} LIGHTS \word{DECIMAL} \\ 2. & \word{:} LIGHT \word{p} n -{}- ) LIGHTS OUTPUT \word{;} \\ 3. & \\ 4. & \word{VARIABLE} DELAY \\ 5. & \word{:} SLOW 500 DELAY \word{!} \word{;} \\ 6. & \word{:} FAST 100 DELAY \word{!} \word{;} \\ 7. & \word{:} COUNTS 256 0 \word{DO} \word{I} LIGHT \quad DELAY \word{@} \word[facility]{MS} \quad \word{LOOP} \word{;} \\ 8. & \\ 9. & \word{:} LAMP \word{p} n -{}- ) \quad \word{CREATE} \word{,} \quad \word{DOES} \word{p} a -{}- n ) \quad \word{@} \word{;} \\ 10. & 1 LAMP POWER~~~ ~2 LAMP HV~~~~ 4 LAMP TORCH \\ 11. & 8 LAMP SAMPLING 16 LAMP IDLING \\ 12. & \\ 13. & \word{VARIABLE} LAMPS \\ 14. & \word{:} TOGGLE \word{p} n -{}- ) LAMPS \word{@} \word{XOR} \word{DUP} LAMPS \word{!} LIGHT \word{;} \\ 15. & \\ \hline \end{tabular} \normalfont \caption{Forth source block containing words that control a set of LEDs} \label{fig:block} \end{center} \end{figure} Lines 4 -- 7 contain a simple diagnostic of the sort one might type in from the terminal to confirm that everything is working. The variable \texttt{DELAY} contains a delay time in milliseconds --- execution of the word \texttt{DELAY} returns the address of this variable. Two values of \texttt{DELAY} are set by the definitions \texttt{SLOW} and \texttt{FAST}, using the Forth operator \word{!} (pronounced ``store'') which takes a value and an address, and stores the value in the address. The definition \texttt{COUNTS} runs a loop from 0 through 255 (Forth loops of this type are exclusive at the upper end of the range), sending each value to the lights and then waiting for the period specified by \texttt{DELAY}. The word \word{@} (pronounced ``fetch'') fetches a value from an address, in this case the address supplied by \texttt{DELAY}. This value is passed to \word[facility]{MS}, which waits the specified number of milliseconds. The result of executing \texttt{COUNTS} is that the lights will count from 0 to 255 at the desired rate. To run this, one would type: \begin{quote} \texttt{SLOW COUNTS} \quad or \quad \texttt{FAST COUNTS} \end{quote} at the terminal. Line 9 provides the capability of naming individual lamps. In this application they are being used as indicator lights. The word \texttt{LAMP} is a defining word which takes as an argument a mask which represents a particular lamp, and compiles it as a named entity. Lines 10 and 11 contain five uses of \texttt{LAMP} to name particular indicators. When one of these words such as \texttt{POWER} is executed, the mask is returned on the stack. In fact, the behavior of defining a value such that when the word is invoked the value is returned, is identical to the behavior of a Forth \word{CONSTANT}. We created a new defining word here, however, to illustrate how this would be done. Finally, on lines 13 and 14, we have the words that will control the light panel. \texttt{LAMPS} is a variable that contains the current state of the lamps. The word \texttt{TOGGLE} takes a mask (which might be supplied by one of the \texttt{LAMP} words) and changes the state of that particular lamp, saving the result in \texttt{LAMPS}. In the remainder of the application, the lamp names and \texttt{TOGGLE} are probably the only words that will be executed directly. The usage there will be, for example: \begin{quote} \texttt{POWER TOGGLE} \quad or \quad \texttt{SAMPLING TOGGLE} \end{quote} as appropriate, whenever the system indicators need to be changed. The time to compile this block of code on that system was about half a second, including the time to fetch it from disk. So it is quite practical (and normal practice) for a programmer to simply type in a definition and try it immediately. In addition, one always has the capability of communicating with external devices directly. The first thing one would do when told about the lamps would be to type: \begin{quote}\ttfamily \word{HEX} FF 40 OUTPUT \end{quote} and see if all the lamps come on. If not, the presumption is that something is amiss with the hardware, since this phrase directly transmits the ``all ones'' mask to the device. This type of direct interaction is useful in applications involving custom hardware, as it reduces hardware debugging time. \section{Multiprogrammed systems} % C.6 Multiprogrammed Forth systems have existed since about 1970. The earliest public Forth systems propagated the ``hooks'' for this capability despite the fact that many did not use them. Nevertheless the underlying assumptions have been common knowledge in the community, and there exists considerable common ground among these multiprogrammed systems. These systems are not just language processors, but contain operating system characteristics as well. Many of these integrated systems run entirely stand-alone, performing all necessary operating system functions. Some Forth systems are very fast, and can support both multi-tasking and multi-user operation even on computers whose hardware is usually thought incapable of such advanced operation. For example, one producer of telephone switchboards is running over 50 tasks on a Z80. There are several multiprogrammed products for PC's, some of which even support multiple users. Even on computers that are commonly used in multi-user operations, the number of users that can be supported may be much larger than expected. One large data-base application running on a single 68000 has over 100 terminals updating and querying its data-base, with no significant degradation. Multi-user systems may also support multiple programmers, each of which has a private dictionary, stacks, and a set of variables controlling that task. The private dictionary is linked to a shared, re-entrant dictionary containing all the standard Forth functions. The private dictionary can be used to develop application code which may later be integrated into the shared dictionary. It may also be used to perform functions requiring text interpretation, including compilation and execution of source code. \section{Design and management considerations} % C.7 Just as the choice of building materials has a strong effect on the design and construction of a building, the choice of language and operating system will affect both application design and project management decisions. Conventionally, software projects progress through four stages: analysis, design, coding, and testing. A Forth project necessarily incorporates these activities as well. Forth is optimized for a project-management methodology featuring small teams of skilled professionals. Forth encourages an iterative process of ``successive prototyping'' wherein high-level Forth is used as an executable design tool, with ``stubs'' replacing lower-level routines as necessary (e.g., for hardware that isn't built yet). In many cases successive prototyping can produce a sounder, more useful product. As the project progresses, implementors learn things that could lead to a better design. Wiser decisions can be made if true relative costs are known, and often this isn't possible until prototype code can be written and tried. Using Forth can shorten the time required for software development, and reduce the level of effort required for maintenance and modifications during the life of the product as well. \section{Conclusion} % C.8 Forth has produced some remarkable achievements in a variety of application areas. In the last few years its acceptance has grown rapidly, particularly among programmers looking for ways to improve their productivity and managers looking for ways to simplify new software-development projects.