Re: BiiN system

[Erik Magnuson <erik@fl.ensco.com>]

dewar@cs.nyu.edu (Robert Dewar) writes:
> I disagree, it was not ahead of its time, it was behind its time. It
> represented a trend in CISC design thinking that at this stage I think
> has been effectively discredited. The 432 itself was clearly an impossible
> design (and the performance of the initial silicon was, as one would expect,
> truly dreadful, and I doubt even Intel with all its techniques for making
> crufty CISC designs chug along at a respectable speed, could have rescued
> it. In many ways the 432 represented the direction of the VAX extended
> even further, and it is interesting to note that DEC itself did NOT
> make the mistake of attempting to do that.

The BiiN system did not use the 432, but instead a variant of the Intel
80960 (the version that was later called the 80960MX.)  On John Mashey's
comp.arch "RISCiness" scales, the 80960 falls in the "hybrid" category
near the Clipper and the AMD29000. However, that was just for the core
instruction set; the MX had extra hardware for all kinds of system functions
like the capability checking Dave described, hardware scheduling of
processes, and the like.  When BiiN was shut down, the 80960 was competitive
with the competition (e.g. MIPS R3000) especially when you consider that all
BiiNs were multiprocessor capable with good scalability up to 8 processors.
(and BTW, Ada tasks were mapped to schedulable entities.)

Here is where the RISC/CISC debate truly comes into focus. The hardware
support for multiprocessing made building multiprocessor machines (and the
software to support them) comparatively easy as long as you liked how the
hardware handled things. But if you did NOT like how the hardware did it
(e.g. there were 32 hardware priorities and you wanted 256 priorities) you
had paid the price w/o being able to reap the benefits.

ObAda:
One way BiiN was ahead of it's time was it's Ada compiler. Since the
compiler was used to build their OS, it was good before it was validated
(e.g. the first goal of the compiler team was to produce something that
could be used to build a real system, validation came only a few months
before the scheduled ship date.)  The support for package Machine_Code was
so good there was no separate assembler available (or needed.)  It was also
the closest thing to an Ada95 compiler seen back then with support for
extensible objects (using the capability objects), child packages (well, not
quite, but you could add new procedures to the bottom of a package w/o
obsoleting the clients of a package), true unsigned (modular) integer
support, and more.

-- 
Erik Magnuson, ENSCO    erik@fl.ensco.com
MARSS-REPL              (407) 254-4122 x260