[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