BiiN system

BiiN system

[Robert C. Leif, Ph.D.]

To: David Wheeler
From: Bob Leif

You wrote
-------------------------------------------------------------------------------
" David Wheeler <wheeler@APHRODITE.CSED.IDA.ORG>
Subject: Re: Why couldn't an operating system be written in ada

The BiiN system had an OS written in Ada, as well as a number of
other interesting capabilities (fault-tolerance, capability-based
security, etc.).  However, developing the OS, hardware, and other things
was incredibly costly, and the sales didn't ramp up fast enough
to overcome the $$ invested.

Real OS's are time-consuming to create."
----------------------------------------------------------------------------
If I remember correctly, Siemens and Intel were involved and the operating
system was created for an Intel chip (432 ?) that was designed for Ada. I
also believe it had  very odd input-output architecture. The questions are
what happened to the BiiN source code? And if available, what would happen
if it were hosted on a modern CPU?

Bob Leif
Robert C. Leif, Ph.D., PMIAC,
Vice President & Research Director
Ada_Med, A Division of Newport Instruments
Tel. & Fax (619) 582-0437

Re: BiiN system

[David Emery]

I worked on the BiiN project, and personally I think it failed due to
two reasons:
   1.   terrible marketing
   2.   too far ahead of its time.

It wouldn't be possible to port the Biin operating system to another machine,
since it depended on the hardware.  The hardware was an outgrowth of the
i432, and was a capability machine.  'Words' were actually 33 bits long,
and the 33rd bit indicated a capability.  This bit was set by the hardware,
and provided substantial security features.   Here's a description of how
this worked, from (10 year old) memory. 

When the 33rd bit was set, the word was interpreted as an 'access descriptor',
or "fancy pointer".  If I remember right, the interpretation of the bits 
was:
       1-20: Object ID
      21-23: Access rights (25 was 'read', 26 was 'write' and 27 was 'control'
      24-31: Type descriptor
The high bits indicated the hardware type, which corresponds to the Ada95
tag or the C++ class indication.  When you dereferenced an access descriptor,
what happened was that the type descriptor bits and object ID were used to
determine if the object was in memory. If it wasn't in memory, then a 
"object fault" was generated.  The type descriptor was used to get a
"load this object into memory" operation, which then used information
stored on disk to access the object and bring it into memory ("activating" it.)

This was all done in hardware, with a little bit of software support to
set up the tables, etc.  The rest of the system was very much built on 
the hardware's support for "objects".  And, when stored on disk, an
access descriptor (AD) also included something that identified the machine 
where the actual value was stored.  So you could have a local AD that pointed
to data on another machine in the network.  The operating system and hardware
worked together in one of the best examples of systems engineering I've
ever seen.  

You can search the literature for articles by Fred Pollack and Kevin Kahn
from the 1985-1987 timeframe.

With 20-20 hindsite, the BiiN machine would have been a perfect platform for
"modern" OO languages, such as Ada95, C++ or Eiffel.  It's a damn shame
that the corporation couldn't make it work.  

               dave

Re: BiiN system

[Robert Dewar]

Dave said

"With 20-20 hindsite, the BiiN machine would have been a perfect platform for
"modern" OO languages, such as Ada95, C++ or Eiffel.  It's a damn shame
that the corporation couldn't make it work."

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.

Furthermore, it is likely that Intel itself will make a major shift at
some point (after all the P6 is really nothing but a pretty standard
RISC machine with a clever front end for translating 32-bit x86
code reasonably fast and efficiently -- it is really rather extraordinary
that we have a nice machine at the heart of the p6, which would be much
easier to generate good code for, but instead the compiler has to struggle
away generating junk x86 instructions, which are then converted back to
reasonable RISC code at runtime. The workings of the marketplace and he
demands of backwards compatibility sure create some odd technical
monstrosities :-)

Re: BiiN system

[David Emery]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]


In article <dewar.837604422@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> Dave said
> 
> "With 20-20 hindsite, the BiiN machine would have been a perfect platform for
> "modern" OO languages, such as Ada95, C++ or Eiffel.  It's a damn shame
> that the corporation couldn't make it work."
> 
> 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.

I don't think that the CISC/RISC debate is anywhere near over yet.  After
all, RBKD has often posted notes about how difficult it is to generate good
code for "modern" RISC architectures.

In particular, it's not clear to me that the underlying notion of Capability
has been discredited.  The beauty of the BiiN system was not the hardware
or the software, but the System that�came from the combination.  In particular,
the system did a wonderful job with two specific areas, Security and Network
computing, that haven't been particularly solved by other technologies.  
And the BiiN design also provided substantial support for system fault
tolerance, another area where we don't have the "final word" yet.  

Incidentally, the BiiN architecture lives on in variants of the i960
chips that have been fairly widely used in avionics...


               dave

Re: BiiN system

[Michael Feldman]

In article <emery-1607962036250001@line200.nwm.mindlink.net>,
David Emery <emery@grebyn.com> wrote:
>
>With 20-20 hindsite, the BiiN machine would have been a perfect platform for
>"modern" OO languages, such as Ada95, C++ or Eiffel.  It's a damn shame
>that the corporation couldn't make it work.  
>
>               dave

I took a 3-day course from Intel on the 432, back around 1982. I still
have docs from that course. The Ada compiler developed for that chipset
was _most_ interesting. It was VMS-hosted, 432-targeted, and pre-Ada 83.
Had some really interesting OO features that also happened to take
advantage of the 432 architecture.

Much of the 432 Ada compiler team was picked up by Verdix when Intel
dropped the 432. That group became the core of the Verdix Ada compiler
team; some are still at it, now under the Rational umbrella.

Somewhere in my morass of papers I have a brief description of the
432 Ada language. I'll pull it out one of these days. Would it be
useful - and legal - to put it in electronic form and get it on the
net as an interesting discussion piece?

Mike Feldman

Re: BiiN system

[David Emery]

In article <4sr56l$2vh@felix.seas.gwu.edu>, mfeldman@seas.gwu.edu (Michael
Feldman) wrote:

...
> Somewhere in my morass of papers I have a brief description of the
> 432 Ada language. I'll pull it out one of these days. Would it be
> useful - and legal - to put it in electronic form and get it on the
> net as an interesting discussion piece?
> 
> Mike Feldman

Elliot Organic wrote a book on the i432 that was very good.  The book
included a description of the Ada extensions.  Someone borrowed my copy
and never returned it :-(

            dave

Re: BiiN system

[Erik Magnuson]

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