ir230@sdcc6.ucsd.edu (john wavrik) (05/07/91)
ARCHITECTURE and IMPLEMENTATION
These are very important words for talking about Forth. Forth is
based on architecture -- most of the words in the language refer
to architectural features. The word architecture is being used
here to emphasize a similarity of that which underlies Forth with
the architecture of a real processor. We use this word,
conventionally, to refer to the layout of registers of a real
machine and also to some features of the machine language (what
kinds of addressing modes will function with which registers, which
regis-ters can be used as hardware stack pointers, etc.)
We are using the word ARCHITECTURE here to refer to the virtual
processor on which Forth is based -- and to which its most impor-
tant commands refer.
The parameter stack is an ARCHITECTURAL feature that everyone (I
hope) agrees is an essential part of Forth. Many of Forth's words
describe operations that belong to this architectural feature. The
idea that words communicate by using the stack is an agreement
about how this architectural feature is to be legitimately used.
Let us, then, make the following distinction: the stack together
with agreements about words used to manipulate it is ARCHITECTURE.
Where the stack is located in memory on a real processor, which
register is used for the stack pointer, etc. is IMPLEMENTATION.
To make the language portable, we try to avoid using features of
IMPLEMENTATION. To make the language useful, we *must* specify
features of the ARCHITECTURE.
The problem that Forth faces is that, during the past 6 years,
there have appeared languages which are called "Forth" but which
differ from one another (and from traditional Forth) in matters of
architecture. Because they differ in architecture, they are actu-
ally different languages. They differ in what can be done using
them. They differ in how things are done. They differ in behavior.
It only adds to the chaos and confusion to pretend they are vari-
ants of the same language. Let us refer to them as FORTH1, FORTH2,
etc. without making precise whose version of Forth is which.
Here are just a few of the architectural differences:
There is much more to Forth than a parameter stack -- but even
concerning just the parameter stack there are architectural deci-
sions which have a great deal of bearing on the power of the
language.
- Does the user have access to the stack pointer?
- Can the user change the address of the stack pointer?
- Can the user index into the stack?
These are areas in which FORTHx may differ from FORTHy. If, for
example, the user has access to the stack pointer and can change
its value, we obtain a much more powerful language than one which
does not allow this access.
Forth also has a return stack and words like >R R@ R>. Again there
is a spectrum. In FORTHx, a user may have full access to the
return stack pointer -- and may make use of the fact that the
return stack stores return addresses. In FORTHy the user is only
allowed to use the return stack for temporary storage. FORTHx
provides the user greater control over the language than FORTHy.
In FORTHx the user can define exception handling mechanisms, for
example, that must be provided in FORTHy.
To make Forth extensible, we have another architecture feature:
the dictionary. It is of major importance to the specification of
the language how this feature is treated: how it is searched, the
composition of its entries, whether it appears as a linked list or
some other data structure, the type of control a user has over
search order, etc.
FORTHx and FORTHy may also differ in the control provided over the
process of compilation. Traditional Forth, for example, allows the
user to know and make use of knowledge of what is "compiled" (or
more accurately assembled) -- and to exercise total control over
the process. Here the user is provided control over what would
conventionally be "the compiler". FORTHy may provide very little
control over the process of compilation beyond what conventional
languages provide (which is pretty much restricted to the use of
standard control structures) -- or may provide control but only in a
(real) machine dependent way.
Another area of difference is in the control provided over the
input and output streams -- whether the user has control over the
input buffer pointer, can manipulate the location and contents of
the input buffer, can redirect output, etc.
Some of these languages are more powerful than others -- in that
they allow more control over language features and allow the user
to do more. Others are designed to provide increased execution
speed (on a particular processor) in trade for power. Some are
really interactive front-ends for other languages.
At its most powerful, Forth can (and has) been used to implement a
variety of features found in other languages -- and, indeed, has
been used to implement other languages! At the opposite end of the
spectrum is a "front-end" version which assumes that major pro-
gramming will be done in some other language -- with Forth being
used to provide an interactive environment.
The existence of a collection of Forth-like language variants
presents a problem if one would like to produce a standard, port-
able Forth. There are good ways and bad ways to attempt a stand-
ardization effort. Let me mention some bad ways:
One bad way is to try to produce a standard by reducing each
architectural feature to the lowest common denominator: if you can
do something in all FORTHx but not FORTHy, then eliminate the
feature. This has the effect of making standard Forth only as
capable in every area as the least capable of the FORTHx -- stand-
ard Forth becomes crippled Forth.
Another bad way is to be vague about architecture, to stretch
definitions, or try to pretend architecture doesn't exist. This
has the effect of hobbling standard Forth -- because words which
do not have a well defined and consistent meaning soon become
useless for portable programming.
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 Mitch.Bradley@ENG.SUN.COM (05/08/91)
The distinction between architecture and implementation is indeed important. However, the place where one chooses to draw the line between what is architecture and what is implementation is purely arbitrary. In a spectrum from "abstract" to "concrete", FIG-Forth and its derivatives drew the dividing line between architecture and implementation rather close to the "concrete" end of the spectrum. The trend in recent years has been to move the line in the "abstract" direction. > The problem that Forth faces is that, during the past 6 years, > there have appeared languages which are called "Forth" but which > differ from one another (and from traditional Forth) in matters of > architecture. Because they differ in architecture, they are actually > different languages. This is true only if people agree where the dividing line is and ought to be. Personally, I believe that the dividing line should be toward the "abstract" end of the spectrum. I base this on the observation that "non-traditional" Forth systems have been quite successful in the marketplace of late, often at the expense of more traditional "model-based" implementations. Even if we all decide to agree that a model-based "concrete" architecture is the way to go, I doubt that it will keep Forth implementors from taking an abstract view of what Forth is, and thus achieving speed advantages on real machines. Users have voted by purchasing fast implementations. You can try to lead people by telling them which way to go, but the most successful leaders lead people in the way they already want to go. I think the marketplace has already decided in favor of the abstract approach. Mitch.Bradley@Eng.Sun.COM