This page (revision-4) was last changed on 03-Feb-2023 15:21 by Carsten Strotmann 

This page was created on 25-Apr-2010 20:23 by Carsten Strotmann

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
4 03-Feb-2023 15:21 35 KB Carsten Strotmann to previous
3 25-Apr-2010 20:37 35 KB Carsten Strotmann to previous | to last
2 25-Apr-2010 20:28 36 KB Carsten Strotmann to previous | to last
1 25-Apr-2010 20:23 36 KB Carsten Strotmann to last

Page References

Incoming links Outgoing links
What is Forth
What is Forth

Version management

Difference between version and

At line 114 changed 13 lines
The C, Pascal, and Modula II languages are typically imple-
mented as native code compilers, and true interpreters for
these languages (when they exist at all) are usually slow
and cumbersome. Although the so-called integrated environ-
ments for these languages, beginning with Turbo Pascal in
1983, have improved programmer productivity immensely, the
environments are really just coresident editors, compilers,
and linkers with a shell that allows the programmer to jump
quickly from one to the other. They are not interpretive en-
vironments: you cannot invoke any language element, or a
procedure you have written yourself, interactively by typing
its name together with some parameters and look at the re-
sults.
The C, Pascal, and Modula II languages are typically implemented as native code compilers, and true interpreters for these languages (when they exist at all) are usually slow and cumbersome. Although the so-called integrated environments for these languages, beginning with Turbo Pascal in 1983, have improved programmer productivity immensely, the environments are really just coresident editors, compilers, and linkers with a shell that allows the programmer to jump quickly from one to the other. They are not interpretive environments: you cannot invoke any language element, or a procedure you have written yourself, interactively by typing its name together with some parameters and look at the results.
At line 128 changed 14 lines
Forth, on the other hand, is the original interpretive, in-
teractive, integrated environment. In typical systems, the
editor, assembler, and various debugging utilities are writ-
ten in Forth itself and are kept resident at all times. The
source code for these tools is usually kept on-line, so that
the programmer can tune them to his personal taste. Although
Forth has been implemented in many ways, the "classic" im-
plementation is an unified interpreter and incremental com-
piler based on some startlingly simple concepts and ground
rules. The core of the interpreter/compiler is a loop which
reads blank-delimited tokens from the input stream (which
can be either the keyboard or blocks of text from mass sto-
rage); the disposition of each token is controlled by the
global variable STATE.
Forth, on the other hand, is the original interpretive, interactive, integrated environment. In typical systems, the editor, assembler, and various debugging utilities are written in Forth itself and are kept resident at all times. The source code for these tools is usually kept on-line, so that the programmer can tune them to his personal taste. Although Forth has been implemented in many ways, the "classic" implementation is an unified interpreter and incremental compiler based on some startlingly simple concepts and ground rules. The core of the interpreter/compiler is a loop which reads blank-delimited tokens from the input stream (which can be either the keyboard or blocks of text from mass storage); the disposition of each token is controlled by the global variable STATE.
At line 143 changed 38 lines
When STATE is FALSE, the system is said to be "interpre-
ting." Each token is looked up in the dictionary; if found,
the corresponding code is executed. If the token is not fo-
und, the interpreter attempts to convert it into a number
which is left on the parameter stack; if the conversion is
unsuccessful the interpreter issues an error message, clears
the stack, and waits for a new command. When STATE is TRUE,
the system is "compiling" a new definition. If the token is
found in the dictionary, some representation of the word
(usually just a pointer) is compiled for later execution. If
the token is not found but can be converted to a number, co-
de is generated which will push that value onto the parame-
ter stack when the new definition is executed. In other
words, each "compiled" Forth definition is just a list of
addresses and literal data, called "threaded code." The ad-
dresses refer, directly or indirectly, to executable machine
code. When threaded code is "executed," a short routine cal-
led the "inner interpreter" walks down the lists of address-
es and runs the corresponding machine language procedures.
As soon as a definition has been compiled, it can be inter-
preted "executed interactively by typing its name" or it can
be referenced in subsequent definitions. All definitions in
a Forth system have equal status, and there is no distincti-
on or artificial barrier between the definitions that con-
stitute the lower layers of the system (including the inter-
preter/compiler) and those added later as part of an appli-
cation. An entire Forth program is run by just entering the
name of its "highest definition." There are two special cla-
sses of words which make the Forth compiler work: 'defining
words' and 'immediate words'. Defining words create a new
entry in the dictionary " that is, add a new symbol to the
symbol table " and trigger the construction of a new variab-
le, constant, procedure, or other object. The defining word
that begins a new procedure " the colon (:) " changes STATE
from false to true and thus initiates compilation. The ap-
plication programmer creates new classes of Forth language
objects by defining new defining words, and creates new mem-
bers of the classes by invoking the new defining words.
When STATE is FALSE, the system is said to be "interpreting." Each token is looked up in the dictionary; if found, the corresponding code is executed. If the token is not found, the interpreter attempts to convert it into a number which is left on the parameter stack; if the conversion is unsuccessful the interpreter issues an error message, clears the stack, and waits for a new command. When STATE is TRUE, the system is "compiling" a new definition. If the token is found in the dictionary, some representation of the word (usually just a pointer) is compiled for later execution. If the token is not found but can be converted to a number, code is generated which will push that value onto the parameter stack when the new definition is executed. In other words, each "compiled" Forth definition is just a list of addresses and literal data, called "threaded code." The addresses refer, directly or indirectly, to executable machine code. When threaded code is "executed," a short routine called the "inner interpreter" walks down the lists of addresses and runs the corresponding machine language procedures. As soon as a definition has been compiled, it can be interpreted "executed interactively by typing its name" or it can be referenced in subsequent definitions. All definitions in a Forth system have equal status, and there is no distinction or artificial barrier between the definitions that constitute the lower layers of the system (including the interpreter/compiler) and those added later as part of an application. An entire Forth program is run by just entering the name of its "highest definition." There are two special classes of words which make the Forth compiler work: 'defining
words' and 'immediate words'. Defining words create a new entry in the dictionary " that is, add a new symbol to the symbol table " and trigger the construction of a new variable, constant, procedure, or other object. The defining word that begins a new procedure " the colon (:) " changes STATE from false to true and thus initiates compilation. The application programmer creates new classes of Forth language objects by defining new defining words, and creates new members of the classes by invoking the new defining words.
At line 182 changed 12 lines
Immediate words are so called because they are always execu-
ted immediately regardless of the value of STATE. The most
important immediate words are the control structure words
and the semicolon (;). The control structure words (such as
IF or BEGIN) perform syntax checking and then generate app-
ropriate code; for example, IF generates code which tests
the value on top of the parameter stack and then performs a
conditional branch on the result. The semicolon (;) is the
terminator for a definition previously begun with the colon
(:), its main action is to change the value of STATE back to
FALSE. The application programmer extends the Forth compiler
by defining new immediate words.
Immediate words are so called because they are always executed immediately regardless of the value of STATE. The most important immediate words are the control structure words and the semicolon (;). The control structure words (such as IF or BEGIN) perform syntax checking and then generate appropriate code; for example, IF generates code which tests the value on top of the parameter stack and then performs a conditional branch on the result. The semicolon (;) is the terminator for a definition previously begun with the colon (:), its main action is to change the value of STATE back to FALSE. The application programmer extends the Forth compiler by defining new immediate words.
At line 195 changed one line
$ 5. 'The Forth Operating System'
!'The Forth Operating System'
At line 197 changed 22 lines
For the first ten years of Forth's existence, it was always
implemented and sold as a "native" system. That is, not only
was it a programming environment, it was the whole environ-
ment. Native Forth systems contain their own device drivers
and do not run under the control of a host operating system;
they take over the entire machine. Moore's goals were speed
and compactness at any price, and he was perfectly willing
to give up the benefits of hardware independence and file
systems in return. Forth interpreter/compilers that ran un-
der host operating systems did not appear until 1979, in the
first wave of small software houses that appeared at the ti-
me of the FIG-Forth listings. Two of the pioneers in this
area were Laboratory Microsystems Inc., which sold a Z-80
Forth for CP/M that used operating system calls for I/O and
file management, and Micromotion, which created a similar
system for the Apple II. Over time, the advantages of host
OS-based Forth interpreter/compilers became obvious, and to-
day about 80% of the Forth programming systems sold fall in-
to this category. So far as I am aware, FORTH Inc. is the
only company still selling native Forth systems as a packa-
ged product, but it now also produces systems that run under
MS-DOS, RSX-11, and VAX VMS (among others).
For the first ten years of Forth's existence, it was always implemented and sold as a "native" system. That is, not only was it a programming environment, it was the whole environment. Native Forth systems contain their own device drivers and do not run under the control of a host operating system; they take over the entire machine. Moore's goals were speed and compactness at any price, and he was perfectly willing to give up the benefits of hardware independence and file systems in return. Forth interpreter/compilers that ran under host operating systems did not appear until 1979, in the first wave of small software houses that appeared at the time of the FIG-Forth listings. Two of the pioneers in this area were Laboratory Microsystems Inc., which sold a Z-80 Forth for CP/M that used operating system calls for I/O and file management, and Micromotion, which created a similar system for the Apple II. Over time, the advantages of host OS-based Forth interpreter/compilers became obvious, and today about 80% of the Forth programming systems sold fall into this category. So far as I am aware, FORTH Inc. is the
only company still selling native Forth systems as a packaged product, but it now also produces systems that run under MS-DOS, RSX-11, and VAX VMS (among others).
At line 220 changed 12 lines
In embedded applications, of course, Forth continues to be
used in its native incarnation to reduce hardware require-
ments to a minimum. A special type of Forth compiler, called
a target compiler, runs on a full-fledged development system
and creates a stand-alone executable image (which can be
ROMable). The image is then transferred to the target system
by any convenient means " ROM, EPROM, downloading over a se-
rial link, or diskette. Naturally, a target compiler can al-
so be a cross compiler; since the target compiler itself is
written in Forth, the CPU upon which the executable image is
compiled need not be the same as the CPU upon which the ima-
ge will be executed.
In embedded applications, of course, Forth continues to be used in its native incarnation to reduce hardware requirements to a minimum. A special type of Forth compiler, called a target compiler, runs on a full-fledged development system and creates a stand-alone executable image (which can be ROMable). The image is then transferred to the target system by any convenient means " ROM, EPROM, downloading over a serial link, or diskette. Naturally, a target compiler can also be a cross compiler; since the target compiler itself is written in Forth, the CPU upon which the executable image is compiled need not be the same as the CPU upon which the image will be executed.
At line 233 changed one line
$ 6. 'The Forth Philosophy'
!'The Forth Philosophy'
At line 235 changed 12 lines
If Forth has a credo, it might be summed up as smallness,
simplicity, and speed. Forth programmers traditionally dis-
dain the flashy user interfaces and elaborate error handling
that characterize most integrated environments nowadays.
This attitude has its benefits " for example, a self-contai-
ned interactive Forth system including an editor, assembler,
and even multitasking support can easily be put in an 8 KB
EPROM. It also has its drawbacks " runtime error checking in
a Forth system is virtually absent (unless it happens to co-
me "for free," such as divide-by-zero detection on the Intel
80x86 family). Frequent total system crashes during Forth
program development are taken for granted; indeed, they are
If Forth has a credo, it might be summed up as smallness, simplicity, and speed. Forth programmers traditionally disdain the flashy user interfaces and elaborate error handling that characterize most integrated environments nowadays. This attitude has its benefits " for example, a self-contained interactive Forth system including an editor, assembler, and even multitasking support can easily be put in an 8 KB EPROM. It also has its drawbacks " runtime error checking in a Forth system is virtually absent (unless it happens to come "for free," such as divide-by-zero detection on the Intel 80x86 family). Frequent total system crashes during Forth program development are taken for granted; indeed, they are
At line 249 changed 9 lines
Corollaries to the Forth credo are that intimate access to
the hardware should always be available and portability sho-
uld never get in the way of exploiting a CPU's instruction
set to its fullest. A Forth system without an assembler is
felt by most to be only slightly better than no Forth system
at all. As for portability, you would be amazed at the num-
ber of arguments in the ANSI Forth Technical Committee that
have hinged on whether a particular language feature can be
implemented efficiently on someone's favorite processor.
Corollaries to the Forth credo are that intimate access to the hardware should always be available and portability should never get in the way of exploiting a CPU's instruction set to its fullest. A Forth system without an assembler is felt by most to be only slightly better than no Forth system at all. As for portability, you would be amazed at the number of arguments in the ANSI Forth Technical Committee that have hinged on whether a particular language feature can be implemented efficiently on someone's favorite processor.
At line 259 changed 11 lines
Classic Forth programming style is characterized by many,
many short, relatively simple definitions, bottom-up design,
prototyping, and successive approximations. Forth dogma has
it that an ideal definition should not exceed 2 or 3 lines
and should not contain more than 9 or 10 elements. This en-
sures that individual definitions can be exhaustively tes-
ted; the programmer can simply put parameters on the stack
and exercise the definition interactively through all of its
possible internal paths. It also constrains an individual
definition from becoming too specific, so that it is more
likely to be reusable in the application.
Classic Forth programming style is characterized by many, many short, relatively simple definitions, bottom-up design, prototyping, and successive approximations. Forth dogma has it that an ideal definition should not exceed 2 or 3 lines and should not contain more than 9 or 10 elements. This ensures that individual definitions can be exhaustively tested; the programmer can simply put parameters on the stack and exercise the definition interactively through all of its possible internal paths. It also constrains an individual definition from becoming too specific, so that it is more likely to be reusable in the application.
At line 271 changed 10 lines
The bottom up design of a Forth application derives natural-
ly from the types of problems to which the language is rou-
tinely applied. A typical Forth application involves intima-
te interaction with hardware to acquire data or control a
machine; in many cases, the hardware itself is only poorly
understood or is not yet stable. The Forth words which are
most hardware dependent are thus usually coded first; when
these definitions are proven and the hardware is well under-
stood, the rest of the application is built up by adding la-
yers of increasing sophistication and complexity.
The bottom up design of a Forth application derives naturally from the types of problems to which the language is routinely applied. A typical Forth application involves intimate interaction with hardware to acquire data or control a machine; in many cases, the hardware itself is only poorly understood or is not yet stable. The Forth words which are most hardware dependent are thus usually coded first; when these definitions are proven and the hardware is well understood, the rest of the application is built up by adding layers of increasing sophistication and complexity.
At line 282 changed 9 lines
The emphasis on prototyping and successive approximations
has much the same grounds as the stress on bottom-up design.
In most Forth applications, getting the hardware to do what
you want puts you a long ways toward your goal. After proto-
typing some code that approximates the final form of the ap-
plication, you can simply discard or modify the upper layers
until you get the specific functionality and user interface
that you need; the lower, more hardware dependent levels of
the application rarely require any significant change.
The emphasis on prototyping and successive approximations has much the same grounds as the stress on bottom-up design. In most Forth applications, getting the hardware to do what you want puts you a long ways toward your goal. After prototyping some code that approximates the final form of the application, you can simply discard or modify the upper layers until you get the specific functionality and user interface
that you need; the lower, more hardware dependent levels of the application rarely require any significant change.
At line 292 changed 12 lines
An important advantage of Forth in application design is
that the documented user interface can rely on Forth's own
interpreter, and merely consist of the top layer of defini-
tions. This offers the sophisticated user incredible flexi-
bility, because not only can he use the documented applica-
tion entry points, he can extend the application by putting
building blocks together in new ways, or access lower level
words to test individual hardware components. In environ-
ments with naive users, the Forth compiler and the interpre-
tation of "dangerous" Forth words are disabled, or an appli-
cation-specific, self-contained user interface is written
that does not lean on the Forth interpreter.
An important advantage of Forth in application design is that the documented user interface can rely on Forth's own interpreter, and merely consist of the top layer of definitions. This offers the sophisticated user incredible flexibility, because not only can he use the documented application entry points, he can extend the application by putting building blocks together in new ways, or access lower level words to test individual hardware components. In environments with naive users, the Forth compiler and the interpretation of "dangerous" Forth words are disabled, or an application-specific, self-contained user interface is written that does not lean on the Forth interpreter.
At line 305 changed one line
$ 7. 'Forth's Place in the Universe'
!'Forth's Place in the Universe'
At line 307 changed 13 lines
In 1969 there was exactly one Forth programmer: Charles Moo-
re. When FORTH Inc. was founded in 1973, there were still
probably less than a dozen. In 1979, Moore estimated that
there were about 1000 Forth programmers. In 1988, based on
the number of packaged systems that have been shipped by the
larger vendors and the copies in print of Leo Brodie's 'Sta-
rting Forth' (a popular Forth primer), I'd conjecture that
there are as many as 50,000 serious Forth programmers and
another 25,000-50,000 casual users. This is certainly res-
pectable growth for a grassroots language. On the other
hand, just to keep things in their proper perspective, some-
thing like 1.5 million copies of Turbo Pascal have been sold
to date, never mind C compilers..
In 1969 there was exactly one Forth programmer: Charles Moore. When FORTH Inc. was founded in 1973, there were still probably less than a dozen. In 1979, Moore estimated that there were about 1000 Forth programmers. In 1988, based on the number of packaged systems that have been shipped by the larger vendors and the copies in print of Leo Brodie's 'Starting Forth' (a popular Forth primer), I'd conjecture that there are as many as 50,000 serious Forth programmers and another 25,000-50,000 casual users. This is certainly respectable growth for a grassroots language. On the other hand, just to keep things in their proper perspective, something like 1.5 million copies of Turbo Pascal have been sold
to date, never mind C compilers.
At line 321 changed 9 lines
Looking back over Forth's somewhat checkered career, I can
identify four distinct phases. I think of the first, span-
ning the years 1969 to 1978, as the "secret weapon" era. Du-
ring this time, Forth evolved rapidly as it was used by a
small set of people on highly specialized, demanding pro-
jects. There was no significant user base whose code would
become obsolete when the language was changed, so many new
concepts could be tried out and added to the language whene-
ver they proved generally useful.
Looking back over Forth's somewhat checkered career, I can identify four distinct phases. I think of the first, spanning the years 1969 to 1978, as the "secret weapon" era. During this time, Forth evolved rapidly as it was used by a small set of people on highly specialized, demanding projects. There was no significant user base whose code would become obsolete when the language was changed, so many new concepts could be tried out and added to the language whenever they proved generally useful.
At line 331 changed 13 lines
The second era, 1978 through 1982, marked the transition of
Forth from a little-known proprietary product to a general
purpose programming language. We could call this the "evan-
gelical era" since it was marked by an intense proselytizing
effort by FIG, augmented by Forth's position as the first
inexpensive structured language with graphics, floating po-
int, and its own editor and assembler on the immensely popu-
lar IBM PC (and later on the Macintosh). In retrospect, we
owe the FIG founders a tremendous debt for legitimizing the
language by seeding the "second-sources." Fortunately for us
all, FORTH Inc. had the foresight not to enforce its trade-
mark on the name "Forth;" I trust they have benefited more
than they have suffered by this policy.
The second era, 1978 through 1982, marked the transition of Forth from a little-known proprietary product to a general purpose programming language. We could call this the "evangelical era" since it was marked by an intense proselytizing effort by FIG, augmented by Forth's position as the first inexpensive structured language with graphics, floating point, and its own editor and assembler on the immensely popular IBM PC (and later on the Macintosh). In retrospect, we owe the FIG founders a tremendous debt for legitimizing the language by seeding the "second-sources." Fortunately for us all, FORTH Inc. had the foresight not to enforce its trademark on the name "Forth;" I trust they have benefited more
than they have suffered by this policy.
At line 345 changed 14 lines
The years 1983 through 1986 were a period of Forth retrench-
ment and disillusionment. Most of the cultists, hobbyists,
and nut cases drifted away from Forth as its novelty faded,
and many of the professionals who continued to use Forth
felt frustrated at its lack of penetration of the computer
mainstream. They were convinced that they had a better solu-
tion for many classes of programming problems, but most com-
puter science departments and the larger trade magazines co-
ntinued to ignore Forth's existence. Smaller Forth vendors
were driven out of business by advertising costs, the effort
required to keep up with rapidly changing PC hardware, pub-
lic domain Forths which could be downloaded from bulletin
board systems, and the vendors' tendency to compete among
themselves instead of trying to broaden the market.
The years 1983 through 1986 were a period of Forth retrenchment and disillusionment. Most of the cultists, hobbyists, and nut cases drifted away from Forth as its novelty faded, and many of the professionals who continued to use Forth felt frustrated at its lack of penetration of the computer mainstream. They were convinced that they had a better solution for many classes of programming problems, but most computer science departments and the larger trade magazines continued to ignore Forth's existence. Smaller Forth vendors were driven out of business by advertising costs, the effort required to keep up with rapidly changing PC hardware, public domain Forths which could be downloaded from bulletin board systems, and the vendors' tendency to compete among themselves instead of trying to broaden the market.
At line 360 changed 28 lines
In 1987, we entered the era of Forth maturation and true
standardization. The ANSI Forth Technical Committee (X3J14),
which operated under the auspices of both CBEMA and the IEEE
Computer Society, made slow but steady progress reconciling
the existing Forth dialects, and the after many revisions
the committee's work was finally approved as the American
National Standard for Forth Programming Language in the
Spring of 1994. While an ANSI Forth Standard will not be an
instant cure for all Forth's ills, it should drastically im-
prove portability of both Forth applications and Forth pro-
grammers, and thus make Forth a more viable candidate for
consideration by project planners. Forth development systems
are available for nearly every CPU in existence, and Forth
is consistently the first third-party high level language to
appear on a new CPU architecture, personal computer, or ope-
rating system. Forth continues to enjoy wide use in real ti-
me control and data acquisition applications, and can be fo-
und in the most unexpected places: from the bar-code-reader
"wand" carried by your friendly Federal Express driver, to
the American Airlines baggage control system, to instrumen-
tation for SpaceLab experiments, to a networked monitoring
and control system with some 400 processors and 17,000 sen-
sors at an airport in Saudi Arabia. While I think it likely
that Forth will always remain a somewhat obscure language,
its speed and interactivity coupled with minimal hardware
requirements and ready portability are a unique combination
of assets. In its niche, Forth has no real competition, and
I expect it will be around for a long time to come.
In 1987, we entered the era of Forth maturation and true standardization. The ANSI Forth Technical Committee (X3J14), which operated under the auspices of both CBEMA and the IEEE Computer Society, made slow but steady progress reconciling the existing Forth dialects, and the after many revisions the committee's work was finally approved as the American National Standard for Forth Programming Language in the Spring of 1994. While an ANSI Forth Standard will not be an instant cure for all Forth's ills, it should drastically improve portability of both Forth applications and Forth programmers, and thus make Forth a more viable candidate for consideration by project planners. Forth development systems
are available for nearly every CPU in existence, and Forth is consistently the first third-party high level language to appear on a new CPU architecture, personal computer, or operating system. Forth continues to enjoy wide use in real time control and data acquisition applications, and can be found in the most unexpected places: from the bar-code-reader "wand" carried by your friendly Federal Express driver, to the American Airlines baggage control system, to instrumentation for SpaceLab experiments, to a networked monitoring and control system with some 400 processors and 17,000 sensors at an airport in Saudi Arabia. While I think it likely that Forth will always remain a somewhat obscure language,
its speed and interactivity coupled with minimal hardware requirements and ready portability are a unique combination of assets. In its niche, Forth has no real competition, and I expect it will be around for a long time to come.
At line 389 changed 3 lines
'This section was originally published as "A Forth Apologia"
in 'Programmer's Journal', Volume 6, Number 6, November/De-
cember 1988, page 56.'
'This section was originally published as "A Forth Apologia" in 'Programmer's Journal', Volume 6, Number 6, November/December 1988, page 56.'
This page (revision-4) was last changed on 03-Feb-2023 15:21 by Carsten Strotmann  Top