Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
What were the earliest Forth programming language implementations for 8-bit personal computers? Was it FIG Forth? Or a predecessor? Or some other development?
Why did Forth lose its relative popularity in usage after the advent of 16/32 bit personal computers?
I believe FORTH Inc. provided the first microcomputer version:
FORTH, Inc.'s microFORTH was developed for the Intel 8080, Motorola 6800, and Zilog Z80 microprocessors starting in 1976. Ref
It wasn't until 1978 that the FIG-Forth model became available, based on the 6502 implementation developed by one of FIG's founders, Bill Ragsdale. Ref
My professional programming career began with FORTH, Inc.'s version for the PDP-11 family. It gave 100% control of everything all of the time. While it was a multi-tasking and multi-user system, the implementation was such that these features were co-operative. One user or bad application could disrupt the others. Everyone and every application had 100% control of everything all of the time. It sounds contradictory, but in a non-networked environment of people working together, this was a very efficient system with little operating system overhead.
That was the key to early Forths. The operating system was Forth. The development environment was Forth. The language was Forth. The applications were Forth. (You weren't writing separate programs so much as making Forth bigger.)
Computer scientists were probably horrified at these concepts. Sure it was compact, efficient, quick in both development and execution, and many implementations were free. But it wasn't safe. It wasn't structured. It gave everyone 100% control of everything all of the time. Anathema!
Forth lost its popularity because it is seldom taught, and it breaks too many rules. Running under an operating system does give advantages, such as networking, GUI, and a large number of available applications for the computer. But it has lost part of what made it unique.
My next professional job added Unix computers to the Forth stuff I was doing. Partial control of some things when Unix feels like it. The paradigms were opposite, and it felt disconcerting switching from one to the other. Forth, of course, was available on Unix, but as a program controlled by Unix. (This is how most Forth's are today, running under a larger operating system.) If you really like the language, that's cool. Most managers won't allow its use though, because even as a slave app, it is different to almost everything else, and the number of Forth programmers is relatively small.
Formality is another reason it lost its popularity. Sure it results in fast development, but fast development is not part of modern programming philosophy. "Know what you're going to do before you do it" is. Plan everything out ahead of time. Forth was designed for interactive, iterative development. Try something. Fix it, tweak it, improve it. Okay, the telescope can now spin at the speed, direction, and to the location desired. An hour later, move on to controlling the angle of the telescope relative to the ground. Don't already know what you are going to do. Just do it. (I know there are places that encourage iterative development techniques, but as far as I know it is uncommon, especially in large companies.)
From the Gforth manual section Appendix B Authors and Ancestors of Gforth:
A team led by Bill Ragsdale implemented fig-Forth on many processors in 1979. Robert Selzer and Bill Ragsdale developed the original implementation of fig-Forth for the 6502 based on microForth.
The principal architect of microForth was Dean Sanderson. microForth was FORTH, Inc.'s first off-the-shelf product. It was developed in 1976 for the 1802, and subsequently implemented on the 8080, the 6800 and the Z80.
Regarding Forth on the 6502, Forth Inc's Forth programming language, history and evolution states:
Bill Ragsdale, a successful Bay Area security system manufacturer, became aware of the benefits of microFORTH, and in 1978 asked FORTH, Inc. to produce a version of microFORTH for the 6502. FORTH, Inc. declined, seeing much less market demand for microFORTH on the 6502 than the more popular 8080, Z80 and 6800 CPUs.
Ragsdale then looked for someone with the knowledge of microFORTH and intimate familiarity with the 6502 to port a version of microFORTH to the 6502. He found Maj. Robert Selzer, who had used microFORTH for an AMI 6800 development system on an Army project and was privately developing a standalone editor/assembler/linker package for the 6502. Selzer wrote a 6502 Forth assembler, and used the Army’s microFORTH metacompiler to target compile the first 6502 stand-alone Forth for the Jolt single board computer.
Forth was available for many of the microcomputers (and some minis) that could be called personal computers when they shipped. Engineers often constructed small Forth Kernels as the engineering department's debugging monitor for new hardware (including many things not PC), and, depending on the culture of the people they were working for, they often made their work available in the early users groups.
Non-engineers often did not know what do with Forth interpreters, and passed over them looking for BASIC.
Also, managers who didn't understand Forth would not allow the engineering debugging monitor to ship in the product, arranging for a conventional one to ship with the hardware instead. Managers who did understand Forth also took it out, to avoid giving the customers too much for their money.
Now, Forth kernels were useful as post-fix integer calculators, but you really wanted a much more complete development environment. That is part of what drove the creation of the fig-Forths -- helping to demonstrate a common set of definitions that could be used, with minimal porting, to construct a full IDE. (Line editor IDEs were still useful back then because we hadn't been spoiled by full-screen editors.)
Reasons Forth did not catch on? It didn't really lose its popularity, it was just totally eclipsed by the Bill Gates machine.
I think there may have been deliberate misinformation, because some thought Forth would not bring the customers back for the add-ons, etc. Gotta have that business plan that guarantees a cash flow.
But there was also a lot of terminology difference. Today we can describe a Forth as an interactive symbol table with fundamental math libraries. The detail of the split stack doesn't even hit radar level any more. It should, because of the now-well-known problems of the stack crash/smash, but I'm not willing to predict that common sense will prevail, even now. (Especially now.)
The terminology and concept differences were deadly.
"Instruction threading" is generating a list of mixed effective op-codes and procedure calls in a virtual machine that cached the return address to reduce call overhead. But people interested in Forth got all tangled up in details of the threading and wasted a lot of time in work that was mostly theoretical exercises in the limits of call optimization and pre-optimized static register usage patterns. It is actually valuable in an academic sense or in a CPU architecture research environment, but it didn't push product out the door, and sometimes made enemies that didn't need to be made.
(I was one of those who wasted considerable time on that.)
"Words" vs. functions/procedures was another terminology difference which was confusing. "Dual stack" was another. I think a better term now would be "split stack".
Postfix notation is a conceptual gap. You could (and some did) write a prefix or infix interpreter for Forths, but that mostly raised hackles. Other purist issues came up about the use of the stack -- whether to limit direct access to the swap/rot range or allow a generalized pick that could pull in operands from arbitrary depth.
Splitting the stack made post-fix natural and simple to implement in the interpreter, but there was really no real reason to avoid infix or prefix. Shoot, the standard word for defining functions is prefix in standard Forth.
The funny thing is that the non-Forth community has wasted a lot of effort support something called a stack frame that is mostly there to give the interleaved stack enough structure that you can safely use the interleaved stack to hold variables. With the split stack, all of the complexity of the stack frame goes away. If you really want a stack frame, it's just pushing the parameter stack pointer with the instruction pointer. The frame pointer can actually be just thrown away on return in most run-times if the stack is split.
And the other funny thing is that the split stack is still ignored as the primary first step in really dealing with the security problems of stack corruption. If you don't want the return address overwritten, don't store it with the parameters and variables.
The 64K boundary was another point of conflict in concepts. In other languages it was not such a big issue, but many early Forths made use of the 16 bit modularity, and there were some purist arguments about that, as well.
Considering the size of a bit-mapped display frame buffer, no one should ever have taken the 64K arguments seriously, but hind-sight is twenty-twenty.
That brings up one more sticking point, which you refer to.
Moving from 16-bit to 32 required a bit of abstraction, and Forth has always been a bit stand-offish about abstraction. To convert a 6800 or 6809 Forth to the 68000, for instance, many just kept the 64K memory model. (Can you imagine?) The actual conversion required going back through the source code carefully, looking for instances of "2 +" sequences that marked incrementing to a next address and changing those to "CELLWIDTH +" or some such. Not just that, of course, but you really had to understand the low-level source and you really had to take time doing it.
For people who had done it before, implementing a new Forth for a new 8-bit CPU was quick and painless when you had a full IDE to start with. Almost all the heavy lifting was high-level. But you couldn't do that when you jumped from 16-bit addresses to 32-bit. You could still do a lot of high-level, but you had to slow down, and the market was cut-throat enough to scare you about slowing down when you weren't sure how much you'd have to slow down.
Now is that more than you thought you wanted to know about this?
Why did Forth lose its relative popularity in usage after the advent of 16/32 bit personal computers?
It didn't have any relative popularity as an 8-bit computer programming language at least, not amongst hobbyists. All 8-bit microcomputers except one came with a BASIC interpreter and BASIC was a much easier language to learn. The one computer that didn't come with BASIC was the Jupiter Ace which had Forth built in instead. The Jupiter Ace was a commercial failure, partly because it didn't have BASIC.
Why was Forth not a success (as a general purpose language)? There are tworeasons, in my opinion:
Forth is a hard language to learn for an absolute beginner. Many people who bought 8-bit micros had never done any programming and so were having to learn how to program. If you're struggling with the basic (sorry about the pun) concepts, an unfamiliar notation is an added difficulty too far.
BASIC programs were lists of instructions in almost English. They weren't much of a stretch from, say, a recipe or a list of directions. Forth programs were lists of words in reverse Polish notation, which can be tricky to grok.
Also, expressions in BASIC were not too far removed from expressions as taught in maths at school. Also, also The concept of a stack can be quite tricky to grasp. You can do a lot with BASIC without knowing what a stack is.
The BASIC monoculture was self sustaining. In the age of 8-bit computing, everybody knew BASIC. If you had a problem with a BASIC program, somebody could help you solve it. If you bought computer magazines, they tended to have program listings in the back that you could type in. These were almost invariably in BASIC.
Forth is a great language with a small footprint, but it is quite low level and definitely quirky. It was never going to be a mainstream success.
That's kind of two questions in one; as to the latter: one of the big benefits of Forth is that it produces threaded code: every new word (/function) is very nearly just an ordered list of of other words to call. So the output tends to be very compact, but not very speedy. Once you've got more RAM, it stops being quite so useful a trade-off.
It's also unusual in being stack based. Postscript is the last surviving stack-based language, as far as I'm aware, and it's rarely used for much beyond data storage. So its swimming against the tide probably didn't help.
As to the former: there were at least two Forths for the Apple II by 1979 — so predating most of the competing machines — Apple Forth by Cap'n Software and AppleFORTH by Programma International. Given the similar names it's probably safe to assume independent but concurrent development, and a lack of preceding competitors.
