From: "Andrew T. Wilson" Newsgroups: comp.compilers,comp.arch Date: 6 May 1996 23:20:32 -0400 Organization: Intel Alaric B. Williams wrote: > > > [I've used systems with completely customizable microcode. They ran > > as though stapled to a snail. -John] > > bill@amber.ssd.hcsc.com (Bill Leonard) wrote: > >Me too! In fact, Data General had a project during the late 70s and > >early 80s to produce such a system. I was working at DG at the time > >and watched this system progress from a dream to a fiasco. > >Originally, it was to have customizable microcode that would be > >tailored to each programming language and to the kernel. Trouble was, > >every system call then resulted in two (very expensive) switches > >between microcode sets. Took 20 minutes (no kidding!) to run the > >Hello world program! Made snails look like speed demons! > > But if you have seperate m-code for each session - that's bad. Just > keep the same opcode set, if switches aren't efficient, which is > likely to be the case. Have a few kernel opcodes, and a handful for > each major-paradigmy language; a VMT lookup for C, something to > traverse lists/trees for LISP and PROLOG, etc. > > If it's slow switching, NO GO. Well, I worked on the Data General FHP, too, (hi Bill), and I'll weigh in with a slightly different take. By the time I left DG (late '82) there were several working prototypes of the FHP. They ran a lot faster than a snail -- in fact, they ran Whetstones, US Steel Cobol benchmarks, etc., a lot faster than VAXen built on similar levels of semiconductor technology. The problem with the original FHP prototype (which was indeed as slow as Bill suggests) was the fact it was lashed together from an FHP "job processor" and a 16-bit Eclipse "I/O processor." Communication between the two was, at first, painfully, terribly slow. Loading from or paging to disk was just abominable. The later generation protos were much improved in this regard. On the FHP, the various flavors of HLL interpreters (called S-languages) were optimized, as Alaric suggests, for the popular languages of the day (Fortran, Cobol, and Ada/Pascal). Writing code generators for FHP was, if not trivial, at least much easier than doing good code generation for 16 or 32-bit minicomputers. I don't think the non-appearance of FHP in the market is a judgment on the technical merit (or lack thereof) on direct architectural support of HLL's. Instead, it was a rational business decision by DG management, who had already launched the Eclipse MV a year before FHP was demonstrable. DG did not have the resources to back two incompatible architectures and time-to-money was firmly with the MV. In retrospect FHP is a wonderful example of what Fred Brooks called the 2nd-system effect. It was architected by DG's leading software developers and contained all the advances they could think of. How advanced was it, you ask? In addition to S-languages for direct HLL support, would you believe * true object orientation with one-level addressing across a network (128 bit pointers!) * A-level secure UNIX-like OS built on a microkernel * full-blown relational DBMS * bit-level addressability for graphics in other words, 'way ahead of its time, but also too radical to develop and debug on the allotted schedule. cheers, atw