From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c9bd72123c9b0d9c X-Google-Attributes: gid103376,public From: Erik Magnuson Subject: Re: BiiN system Date: 1996/07/19 Message-ID: #1/1 X-Deja-AN: 169654947 sender: erik@sulu x-nntp-posting-host: sulu references: <2.2.32.19960716060723.00688abc@mail.cts.com> organization: ENSCO, INC. newsgroups: comp.lang.ada Date: 1996-07-19T00:00:00+00:00 List-Id: 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