Re: Compile HLL to microcode on VLIW - possible?

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
[Sounds just like the S/38 which after a slow start was a big winner. -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.