[ih] BBN C-series computers

Bernie Cosell bernie at fantasyfarm.com
Sat Oct 21 05:58:55 PDT 2017


On 21 Oct 2017 at 13:54, Paul Ruizendaal wrote:

> I'm trying to get a better understanding of the BBN C30, C70 and C60
> machines. Google seems to yield little relevant info for them.
> 
> >From brief references in other documents my understanding is that these
> were microprogrammable machines with 10-bit bytes and 20-bit addresses.
> Maybe they were all the same machine in different configurations.

They were, indeed, machines with 10-bit bytes and 20-bit addresses.  BBN 
designed and built a microprogrammable board precisely to put the IMP 
code on -- Honeywell was discontinuing the H316.  I'm not sure of the 
details about how they ported the IMP code, but I think they were able to 
use the same source code.  That became the C30.

A separate project was to replace the [expensive] PDP 11/70s [I think] 
with an MBB [microprogrammable building block] based Unix system.  The 
original plan was for it to have a lifetime of a year or two, 
anticipating that better/cheaper unix platforms would be available.  We 
worked with the original Unix C-code.   We designed an 'instruction set' 
for the MBB.  Carl Howe wrote the microcode to implement it.  I modified 
a C compiler [running on a 36-bit PDP-10] to produce "MBB microcode" and 
Al Nemeth worked to make it run.

There was never an assembler for the MBB-Unix [which became the C70 when 
we got it working] -- "C" was the only "assembly" code for the system.  
That freed us to make the MBB instruction set quite irregular [with 
different field sizes, different subroutine calls [depending on the 
number of arguments] and other efficiency hacks like that.  We got it 
going surprisingly quickly and Al kept studying the resulting code and 
making suggestions.  Carl would implement them, I'd hack them into the 
compiler, rebuild the system, download into the MBB, and check again.

One I remember was that Al noticed that some large percentage of the 
subroutine calls in the kernel were either zero argument or one-argument 
calls.  So we implemented a second subroutine call instruction that 
always pushed the AC onto the stack and called the subroutine [in one MBB 
cycle] -- similarly there were two 'return' instuctions, one normal and 
one popped a single arg off the stack as it returned.  The compiler 
figured all this out and did the right thing [using the 'long' or 'quick' 
subr call instruction]

Another involved accessing structures.  Al checked the size of structures 
in the kernel and found the predominant "maximum" size, and Carl made 
room in an MBB instruction for a constant of that size, and I had the 
compiler figure out whether it could do an 'indirect and index' into a 
struct in a single instruction (when it could) and the usual struct 
reference code otherwise.

I remember when we decided that the C70 was stable and solid enough that 
it could run its own compiler [now running on a 20-bit machine].  After 
some hacking, we got the on-PDP10 compiler and the on-MBB compiler to 
produce identical results, and we cut the cord: running entirely on the 
[now] C70 itself.  The result of all of this [Al's optimizing, Carl's 
clever microcode and a smart compiler] was that the C70 was *very* fast.  
Much faster than the 11/70.  As a result, it survived for many years past 
its expect lifetime [and was good enough that BBNCC was selling it as 
cost-effective Unix product]

/Bernie\

-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       






More information about the Internet-history mailing list