(See a closeup at Gruner's site.)
Little is publicly known about the Fountainhead Project (FHP). It is mentioned often in Tracy Kidder's book The Soul of a New Machine, but only because it competed with the project that formed the soul of the book, the Eagle Project (which produced the Eclipse MV/8000). Data General is gone, now, absorbed into EMC. The patents that came out of FHP were the subject of a long-running lawsuit between DG and IBM, but EMC settled that suit in about 2000. There are no direct descendents of the Data General computers, as John Faughnan and Sanja Stevanovic note in a report on the Eagle Project they wrote in 1996:
Why should we be interested in a project that led to a now extinct product in a now little known computer company? There are several good reasons. Tracy Kidder wrote a Pulitzer prize winning novel about the Eclipse MV/8000 project (code-named Eagle), titled The Soul of a New Machine. No other information system project has been so well documented from the human perspective. Secondly, the Eagle project did produce a new, high technology product, on a very tight timeline. Thirdly, we can compare the Eagle project to the yet more obscure Fountainhead Project, which took place simultaneously at Data General. Lastly, the project, and what followed, provides a window into a fascinating time in industrial history, and an important example of the strategic management of technology. (Emphasis added)
I joined the FHP project in progress some time in 1978 and I was at the bottom of the pyramid as a novice programmer. So, I don't have any special insight into the origin or the politics of the project at its inception. I know that part of the reason our project was located in the Research Triangle Park was that Ed de Castro, head of DG, was upset with what he consider the high taxes in Massachusetts, where DG was headquartered. There were proposals to increase taxes to even higher levels, and he (and probably other industry leaders) wanted to put pressure on the state by threatening to pull up stakes and go south.
In addition, the new line of 32-bit VAXs from Digital Equipment Corporation (DEC) were coming on line in 1976 with 32-bit architectures. The DG line, which had started with the Nova, a PDP knockoff with an 8-bit architecture and continued with the Eclipse 16-bit architectures, was getting hammered. DG needed an architecture with a bigger address space.
So, partly in response to the VAX 11/780, DG decided to build a computer based on a new "high-level language architecture", as noted by Ron Gruner, the leader of the FHP project. This architecture included all the latest concepts, including:
(See this comment from Gruner for more information.)
S-languages allowed the FHP machine to switch to a microcoded interpreter for the specific language you wanted to use. For example, if you had a program written in FORTRAN, you could, in effect, load in a set of machine language instructions specifically designed to process the program as efficiently as possible. This is the opposite of RISC (Reduced Instruction Set Computing). It's not just Complex Instruction Set Computing, it's kind of the ultimate CISC. If you then switched to COBOL, you could use a different set of instructions, tailored for COBOL object code.
The true object oriented addresses were 128-bit. This is an incomprehensible number. As my boss described it, this was enough to address "all the atoms in the universe". If you consider how fast the CPU could process information, it would have taken approximately the rest of eternity to store information at all those locations. So, the system could doll them out in chunks addressable with 32-bit pointers, the so-called objects. The instructions were equally 128 bits long, so there was plenty of address space for all that CISC.
The operating system was also designed to run in a kind of dual mode. One mode would run the normal Eclipse operating system (AOS) and the other an extended OS (dubbed EOS) for the FHP features. As noted above, it borrowed some of the security ring concepts from operating systems designed for national defense. I didn't work directly on the DBMS, but I remember it as having a lot of capabilities (basically in the form of library calls). This was at the time when relational databases were still new. There was a lively discussion of whether database should be one word or two (as in "data base"). As for the bit-level operations for graphics, we tested them by writing variations of Conway's Game of Life. We also wrote a number of Whetstone and other performance tests. The FHP architecture blew away the VAX and other similar computers of its day, as you can see from the plaque:
(See a closeup at Gruner's site.)
One of the fun things about life on the FHP project was that we got access to some of the forward thinking in computers for that time. Rear Admiral Grace Hopper visited and handed out nanoseconds. (She had an example of a microsecond, but she didn't hand those out because they were too long.) The nanosecond was a short length of copper wire the distance an electrical signal goes in a nanosecond. We also had a video on the Cray 1. Given how long a nanosecond is (in copper), you can see how Cray shaped his computer to get signals around as quickly as possible. You can literally see how the computer was shaped around the nanosecond.
Ultimately, about three prototype FHP machines were built. (I wonder what happened to them.) Sometime around 1980, FHP was cancelled. It simply didn't result in a final product before the Eagle overtook it and became DG's top-line product. By that time, I was working on another project (also at RTP), so I wasn't directly affected.
One of the obvious lessons here is "Don't bite off more than you can chew." But, beyond that, it's interesting to speculate what would have happened if FHP had succeeded. Could it have worked if it hadn't been undermined by a quick fix to the Eclipse line? If DG had been a larger company with more resources to fund the project? If it had simply been managed "better" (whatever that means)? If all the top DG engineers (including Tom West) had moved to RTP and worked on their projects there?
It's hard to tell. But, I think we lost an architecture that had a lot of potential. The system as a whole didn't make it out the door, but I suspect that it was a huge learning experience for the people who worked on it, and that knowledge has been seeded across a lot of other projects.