ir230@sdcc6.ucsd.edu (john wavrik) (12/04/89)
John Wavrik wrote:
# There is an historical precedent for what I am suggesting. About 10 years
# ago, a group of independently minded programmers decided to make a new
# language available to the general public. They implemented their model on
# about a dozen of the most popular processors of the time. Most people who
# got past the unconventional nature of the language found it almost
# supernaturally powerful.
Leo Brotzman replied:
# I presume that you are referring to FIG Forth here. The FIG model was
# precedant setting, but is no longer in widespread use. It has been quite a
# while since I used FIG Forth, but I believe that even it had certain
# implementation differences between processors.
-------
Let me address the historical aspects of Leo's message. Without doing some
research, I can only make this a brief and somewhat personal account. I feel
that the statement that "the FIG model is no longer in widespread use" is
misleading. And this point has a great deal of relevance to the theme of the
discussion.
After a few years of using Forth for my research work, I decided to teach it.
At the time (the early 1980s) this meant using a central computing system. I
discovered that the Center for Astrophysics and Space Studies (CASS) at my
school (UCSD) had a version of Forth for the VAX -- and they were happy to
supply me with a copy.
The CASS version apparently started with a DECUS version for the PDP-11. They
took the original Forth block file idea literally -- my account had two 500
screen block files (which, at the time, were more screens than I thought I'd
use in a lifetime). The CASS version was like an archeological dig. No one
ever erased a screen -- new definitions replaced old. One could see the
evolution of word names and meanings. There was even a control program for a
small telescope among the screens -- which gave an indication of how Forth was
used. My only text was the "Kitt Peak Primer", written in 1979 and already out
of date in 1981. The real flux in Forth seems to have occured between 1969
(which FIG sets as the year of its discovery) and 1979 -- looking at Forth
during this period is exciting: it is a period in which giants wrestled with a
new concept.
The Forth Interest Group did a very interesting thing at about this time. They
defined a language by a model rather than a standard. Their model included a
suggested implementation. As a result, they defined, in fact, a tightly mixed
blend of language, operating system, language implementation, and mapping to a
host processor. Forth is actually the name for Siamese quadruplets!
I told my computer center that I wanted to teach Forth -- and they objected to
the idea of each student using 1 Meg of disk space. I asked them to find
something else and in short order they came up with two alternatives for the
VAX. Each of these had coped with "the user owns the disk" problem in
different ways. One was the version of Forth used by the Jet Propulsion
Laboratory in Pasadena California, the other was the version of Forth used by
the Kitt Peak National Observatory in Tucson Arizona.
JPL-Forth used subroutine threading and text files. It was SLOWER than the
indirect threaded Kitt Peak, less sophisticated, and less well documented.
(In fairness to JPL -- this was an "in house" version which was not intended
for export.)
Kitt Peak VAX-Forth was a "professional" version of Forth. It had to be
installed by the computer center -- but it was equivalent in all respects
(performance, documentation, etc.) to any of the other languages we had
available. Kitt Peak VAX-Forth was a FIG-Forth accompanied by extensions
which its developers found appropriate (it used block files in exactly the
same way as F83 and other modern Forths, it had floating point, it had hooks
to the underlying VMS and Unix operating systems -- and it also established
mechanisms for 16/32-bit compatibility, conditional compilation, multiple data
types sharing the same stack, etc.)
We picked the Kitt Peak -- not only was it more efficient and better
documented, but because many useful utilities (like a decompiler found in
the 1981 Forth Dimensions) could be easily made to run on it. People tend to
forget that the incredible portability of the FIG model was responsible for
interest in the Forth language during the early 1980s.
By the time I wanted to teach, the Forth-79 Standards had appeared. At home I
was using a commercial Forth-79 produced by a software house that made its
money writing Forth applications but also sold the version of Forth it used.
As it turns out, Forth-79 differed from FIG-Forth in only a few words:
WORD -- in FIG it did not leave an address (but the address
was the end of the dictionary)
<BUILDS -- replaced by CREATE
VARIABLE -- required an initial value in FIG-Forth
NUMBER -- I no longer remember the precise difference
At any rate, I made VAX-Forth look like a Forth-79 with a few screens of
adaptation (several years later Martin Tracy was to call this a "prelude").
WHILE BROTZMAN MAY TECHNICALLY CLAIM THAT FIG-FORTH DISAPPEARED AT THIS POINT,
IT WOULD BE MORE ACCURATE TO SAY THAT IT BECAME THE FORTH-79 STANDARD.
The 1983 Standards were different in character than those of 1979. There were
no major changes in the way Forth is implemented (although the 1983 Team
seemed to be the first to try to separate the quadruplets) but the '83 team
had several "better ideas" which produced "gottchas" [for non-English
speakers: a contraction of "I've got you" -- that is, "you've fallen into my
trap" -- it's something said by razors when you try to shave quickly].
The 1983 Standards Team tried to improve the language by "fixing" things they
felt were wrong. As a result, they changed the actions of important words --
some in subtle ways. The change in ' (tic) was up front and visible but I can
vouch for hours spent trying to track down why some '79 code did not run on
'83 (EXPECT-83 does not put a 0 at the end of input the way EXPECT-79 did).
The irritation caused by some of the minor nuisance changes, and the
resulting backlash should not mask two important points: (1) The 1983 Team
did not substantially change the language; (2) Many of their points were well
taken (but not balanced against the effect on portability of earlier code).
The fact of the matter is that a good many versions of Forth, including Laxen
and Perry's F83 (which may be one of the best Forths ever written) are direct
descendants of FIG-Forth.
While the issue of implementation and standards does need to be discussed,
I think it is important to understand that FIG-Forth was not something tried
and abandoned -- quite the reverse!
We are dealing with a language that has a 20 year history. Some of the papers
presented at the recent Forml conference were rediscoveries of ideas which can
be found in the papers and systems of the early 1980's. It is the conceit
of the young to believe that until they were born no one was smart enough to
discover what they have discovered. Fortunately God invented old people to
tell them otherwise. If it were not this way, we would have no progress.
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093
toma@tekgvs.LABS.TEK.COM (Tom Almy) (12/06/89)
In article <5565@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: >Leo Brotzman replied: ># I presume that you are referring to FIG Forth here. The FIG model was ># precedant setting, but is no longer in widespread use. It has been quite a ># while since I used FIG Forth, but I believe that even it had certain ># implementation differences between processors. >The Forth Interest Group did a very interesting thing at about this time.They >defined a language by a model rather than a standard. Their model included a >suggested implementation. As a result, they defined, in fact, a tightly mixed >blend of language, operating system, language implementation,and mapping to a >host processor. Forth is actually the name for Siamese quadruplets! And an excellent idea! I found figFORTH to be the most portable version I ever used because the implementation was defined! Prior to figFORTH I had brief brushings with URTH (University of Rochester forTH) and STOIC, but these (along with Forth Inc's products and MMS Forth -- another early commercial entrant) were totally non portable. I used figForth implementations for 8080, Z-80, 6502, 6809, PDP-11 (and VAX using 11 emulation mode), 8086, and 68000, from different vendors, with complete code portability. I can't say the same for any Standard since. The closest I've been is to treat "F-83" as a standard (which many people do, anyway) in which case there is portability but no large group of vendors. Even with the kernel tied down there was still room for vendor value-added enhancements. A good editor, floating point, graphics, strings, decompilers, an assembler... Also good documentation. And performance could be enhanced. I switched to direct threaded (slight cost in portability) for a 20% speed improvement, as well as changing from name-first to link-first headers which halved compile time. Also, the implementation of multiplication and division (at least for the 8080) was extremely poor. >Kitt Peak VAX-Forth was a "professional" version of Forth. It had to be >installed by the computer center -- but it was equivalent in all respects >(performance, documentation, etc.) to any of the other languages we had >available. Yes, it had a lot of excellent ideas. I thought its implementation of arrays and handling of different sized data types was well thought out and to this day unequaled by any other implementation I have seen. >As it turns out, Forth-79 differed from FIG-Forth in only a few words: > > WORD -- in FIG it did not leave an address (but the address > was the end of the dictionary) > <BUILDS -- replaced by CREATE > VARIABLE -- required an initial value in FIG-Forth > NUMBER -- I no longer remember the precise difference Also DO/LOOP CREATE LITERAL, there were about three packed screens of changes. I converted most of my systems to 79 Standard, too. With clever use of vocabularies (another thing that differed between fig and 79) you could run a bi-version system! >The 1983 Standards Team tried to improve the language by "fixing" things they >felt were wrong. As a result, they changed the actions of important words -- >some in subtle ways. The change in ' (tic) was up front and visible but I can >vouch for hours spent trying to track down why some '79 code did not run on >'83 (EXPECT-83 does not put a 0 at the end of input the way EXPECT-79 did). Interestingly enough, tic was originally "dumb" like it is in the 83 standard. As far as I know, fig-Forth introduced the "smart" tic. I fully agree with the elimination of state smart words since they are confusing and can lead to errors. On the other hand, the change in the definition of division was a major mistake since it made Forth different than any other language as well as any processors divide instruction! That and the ignorance of 32 bit word environments shows the 6502/8080 orientation of the 83 Standard Team. >The fact of the matter is that a good many versions of Forth, including Laxen >and Perry's F83 (which may be one of the best Forths ever written) are direct >descendants of FIG-Forth. An incredible effort. The only unfortunate aspect is that they had to cripple the multitasker so that it couldn't be used in a multi-user environment. You have to balance that against they stole the multitasking technique from the company that didn't want them to issue it multi-user. I hacked on my 8080 version to make it multi-user and ended up with a terrific 3 user version on my 5 Mhz Z-80 system. I even had a printer spooler task so that all users could share the printer (they would print by sending a command line to the printer task), and printing would then progress in the background. Each user had its own "termcap", and the CP/M 3 O.S. had disk cashing which minimized disk thrashing. Of course, nobody really cares about multi-user systems these days, but it was facinating to see it in action. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
jax@well.UUCP (Jack J. Woehr) (12/09/89)
jj wavrick, i really enjoyed that historical stroll thru Forth.
It's amazing how many people don't realize that Forth is an operating
system (among other things). As one whose workday revolves around
standalone Forth, i sigh when I think of the work that people around
the world go to daily to make things more complex than they have
to be.
Forth showed a path for the future, but the future diverged
perversely. Imagine if it had been Forth, not hopelessly crippled BASIC,
that had been provided to every purchase of a late-'seventies micro ???
To which people replied "but everyone KNEW Basic". Everyone knew
how to use an outhouse, too, before they invented indoor plumbing ... :-)
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
{} jax@well ." Sysop, Realtime Control and Forth Board" FIG {}
{} jax@chariot ." (303) 278-0364 3/12/2400 8-n-1 24 hrs." Chapter {}
{} JAX on GEnie ." Tell them JAX sent you!" Coordinator {}
{} jax@well.sf.ca.us {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}marc@noe.UUCP (Marc de Groot) (12/10/89)
In article <6467@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: >In article <5565@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: >>The Forth Interest Group did a very interesting thing at about this time.They >>defined a language by a model rather than a standard. Their model included a >>suggested implementation. As a result, they defined, in fact, a tightly mixed >>blend of language, operating system, language implementation,and mapping to a >>host processor. Forth is actually the name for Siamese quadruplets! > >And an excellent idea! I found figFORTH to be the most portable version I >ever used because the implementation was defined! Prior to figFORTH I had >brief brushings with URTH (University of Rochester forTH) and STOIC, but >these (along with Forth Inc's products and MMS Forth -- another early >commercial entrant) were totally non portable. I used figForth implementations >for 8080, Z-80, 6502, 6809, PDP-11 (and VAX using 11 emulation mode), 8086, >and 68000, from different vendors, with complete code portability. Amen. I ported a complete development system (editor, debugger, decompiler, source-finding utilities) from my 8080 CP/M fig-Forth system to my housemate's LSI-11 system in one afternoon, with ZERO changes to the source. The vast majority of the effort went into establishing an RS-232 link between the computers. >I hacked on my 8080 >version to make it multi-user and ended up with a terrific 3 user version >on my 5 Mhz Z-80 system. I even had a printer spooler task so that all >users could share the printer (they would print by sending a command line >to the printer task), and printing would then progress in the background. >Each user had its own "termcap", and the CP/M 3 O.S. had disk cashing which >minimized disk thrashing. > >Of course, nobody really cares about multi-user systems these days, but it >was facinating to see it in action. Right. ;-) I hacked up my 8080 fig-Forth to multitask. It even had job control! You could type bg wordname to put a Forth word in background. Each task had a fixed portion of RAM which included stack space, dictionary space, and user variables. A task could compile source from the disk and then run it. By playing with the link fields Forth words could be traded between tasks. The fetch and store words did memory bounds checking, which gave a certain amount of memory protection. I wrote an IPC package which was independent of the transport layer and which ran in a "system task". I then ported the system task code to a fig-Forth on an Apple II and ran the IPC package over a serial line, just to show it would work. Terminal I/O was vectored and I could attach my terminal to different tasks by patching the vectors. My housemate and I entertained our- selves by playing "Forth dictionary wars" -- seeing who could crash who with two terminals attached to different tasks. The system was "pre-emptive" rather than "polite": I wanted all the code I had written for Forth to run without inserting PAUSE all over the place to get it to context-switch. I used a 1-byte counter which was decremented. Context switched every 256 (or less) times through NEXT. The number was settable for each task, allowing very flexible scheduling. This mechanism allowed one task to single-step another, by setting the down-counter of the task to 1. This would cause it to switch context after one cycle through next, allowing the controlling task to "grab" control. A task could be made to sleep by setting its counter to 0. BTW, the overhead for all this wonderful stuff: 3% of the CPU time. A single task running on the multiuser system took 3% longer to run than the same task on a single user system. But, like Tom said, nobody cares about multi-tasking systems anymore. Too bad. -- Marc de Groot (KG6KF) |"...few people know what to do with a computer. Noe Systems, San Francisco | They decide that running an operating system UUCP: uunet!hoptoad!noe!marc | is a substitute for doing productive work." Internet: marc@kg6kf.AMPR.ORG | -Chuck Moore
koopman@a.gp.cs.cmu.edu (Philip Koopman) (12/12/89)
> This is getting so nested that I'm not sure *who* wrote ... > >And an excellent idea! I found figFORTH to be the most portable version I > >ever used because the implementation was defined! ... I used MVP-FORTH for many years, and found it extremely portable. My favorite portability story is porting a large floating point math package from an Atari 800 to an IBM PC to a Heathkit Z80 to an Apple II to a WISC CPU/16 without any changes at all. Of course, it was slow, but typically it took less than 24 hours to get the machine code in place for higher speed -- which depended on good factoring techniques. I also ported a 500 screen hotel control system from an Atari 800 to an IBM PC in about a day (lots of I/O code and screen interface in this one, so it took a while). Porting the math package to an F83 system is a bear, because the numeric input words differ and divide is "broken". Perhaps there is something to be said for defining an implementation for a core. It increases portability tremendously. It should not prevent manufacturers from offering product differentiation (which they probably should be doing in the extension set, not in the core anyway). Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.