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: emery@grebyn.com (David Emery)
Subject: Re: BiiN system
Date: 1996/07/16
Message-ID: <emery-1607962036250001@line200.nwm.mindlink.net>#1/1
X-Deja-AN: 169233712
references: <2.2.32.19960716060723.00688abc@mail.cts.com>
organization: MIND LINK! - British Columbia, Canada
newsgroups: comp.lang.ada
Date: 1996-07-16T00:00:00+00:00
List-Id: <comp.lang.ada>


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