[ih] NCP and TCP implementations

Mon Mar 16 13:59:01 PDT 2020

Thanks Andrew - that is consistent with my recollection (I used the C/30's
and C/50s for the MCI Mail backbone network). These machines
presented X.25/X.29/X.75 to the hosts connected to the network.

Did the C/70 really run "C" - surely C programs had to be compiled into
some kind of assembly language??

v

On Mon, Mar 16, 2020 at 4:37 PM Andrew G. Malis via Internet-history <
internet-history at elists.isoc.org> wrote:

> I wrote both code and microcode for the C/30 IMP. We started by
> implementing a straight emulation of the Honeywell 316 architecture and
> instruction set so that we could port the existing IMP code pretty much
> untouched. Once that was working, we then conducted extensive performance
> testing to determine where the code was spending its time, and moved a
> number of expensive (from a CPU perspective) operations, such as queue
> handing and process scheduling, to the microcode. That also allowed us to
> make the queue handing instructions "atomic", which helped
> eliminate possible race conditions without requiring software semaphores
> and the like. We were able to really improve the IMP's forward capacity on
> the fast path though the use of microcode optimization. In the end, the
> C/30 IMP code looked very different from the original 316 code base, even
> though it was still in assembly language (what we now called "C/30
> assembly"). We had talked about porting the code base to C and compiling
> that down to C/30 assembly, but that never ended up happening.
>
> Cheers,
> Andy
>
>
> On Mon, Mar 16, 2020 at 4:09 PM Paul Ruizendaal via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > Dear all,
> >
> > The C/30 and C/70 were discussed on this list in October 2017. I think I
> > recall from then that the MBB project got started because BBN had not
> done
> > a CPU project in a while, Al Nemeth had some ideas and ARPA needed a
> > replacement for the 316/516.
> >
> > This is an excerpt from a message I posted back then:
> >
> > ====
> >
> > The MBB processor:
> >
> > The MBB processor is documented in this paper (available from the ACM
> > library, unfortunately behind a paywall):
> > M. F. Kraley, R. D. Rettberg, P. Herman, R. D. Bressler, and A. Lake,
> > “Design of a User-Microprogrammable Building Block” in Proceedings of the
> > 13th Annual Microprogramming Workshop, IEEE, New York, 1980.
> > It is an interesting read and I can certainly recommend it; it also
> > discusses some aspects of the C/30 and C/70 configurations.
> >
> > The MBB processor seems to have been word (not byte) addressable, with 20
> > bit addresses and data paths. It is highly reminiscent of the Alto, with
> > I/O device controllers partially implemented in microcode. It is also
> > somewhat reminiscent of the TI990 and the later Sparc in that it had 1024
> > registers with a visible window of 16 registers. It is unique in that the
> > processor had two optional daughter boards to customise the system: (i) a
> > board to assist with macro-instruction decoding, (ii) an MMU board.
> >
> > The C/30 version seems to have had a macro-instruction daughter board,
> but
> > with addresses going straight through. When used as an IMP, some 30% of
> > microcycles seem to have gone on I/O processing and the remaining 70% on
> > executing H316 code.
> >
> > The C/70 version had both daughter boards. The MMU board divided the 1MW
> > address space into 128 pages of 4KW, and had protection & dirty bits per
> > page. It could hold page tables for up to 8 tasks. 128 pages by 4KW is
> only
> > 19 bits, perhaps the MMU board used 1 bit to simulate byte accesses.
> > Apparently, there was also a ‘switch’ (IMP?) version of the C/70, without
> > the MMU board and running a minimal OS (but using the “C” microcode &
> > board).
> >
> > The C/70 seems to have implemented a load/store type architecture with 40
> > basic instructions, each offering one of 19 addressing modes in an
> > orthogonal setup. The 19 addressing modes were designed around typical C
> > data access operations. Next to that there were 44 specialised
> instructions.
> >
> > Procedure calls were very fast, as specialised instructions existed to
> > switch to a new register bank as part of the call, with spilling to main
> > memory upon deep recursion. Apparently it was possible for C code to
> ‘call'
> > into microcode, and this may be how system calls were done.
> >
> > ====
> >
> > According to the paper mentioned above, it is all documented in detail in
> > the "MBB Microprogrammer's Handbook" BBN Report No. 4268, Feb. 1980.
> > Unfortunately, this document does not seem to be available on the DTIC
> > website. Maybe this document still exists in the BBN (and successor)
> > library. As the topic comes up from time to time, maybe it could be added
> > to Bitsavers?
> >
> > BBN-UNIX for the C/70:
> >
> > This was a port of the V7 based Unix that BBN had running on the PDP11,
> > with various BSD-type extensions. It had the Gurwitz TCP/IP stack
> > integrated, and accessible via the VAX-TCP API (which was compatible with
> > the earlier NCP Unix API). It also had some of the earlier IPC features
> > (Haverty’s await() and capac() calls, ports, etc.). That TCP stack is
> > available for study on TUHS
> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet (note
> > how the code has #ifdef’s for VAX and MBB).
> >
> > Again from the discussion three years ago, I think this Unix version and
> > the C/30-C/70 were maintained into the late nineties by BBN.
> >
> > There was a commercial version of the C/70 (called the C/60) done by/for
> > the BBN computer division - see for instance this advert:
> >
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN%20C%2F60&f=false
> > <
> >
> https://books.google.nl/books?id=2LaqX2JB6_UC&pg=PA18&lpg=PA18&dq=BBN+C/60&source=bl&ots=Udp4oJD-zO&sig=ACfU3U39YuIjEJ6g1SGYgMqHsil-v6FzdQ&hl=nl&sa=X&ved=2ahUKEwjKtIHh45_oAhWCjKQKHdZoD_EQ6AEwBHoECAgQAQ#v=onepage&q=BBN
> > C/60&f=false>
> >
> > Paul
> >
> >
> > > On Mar 16, 2020, at 7:28 PM, Noel Chiappa via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> > >
> > >
> > >> From: Bernie Cosell
> > >
> > >> The TIP was a 316 IMP with the terminal handling code in the upper 16K
> > >> of memory.  The C/30 was an implementation of the 316 on the MBB
> > >
> > > Any idea/recollection of why the 316 TIP hardware was ditched and
> > replaced
> > > with the C/30 for the TAC? Just to have more modern/maintainable
> > hardware? (I
> > > recall the 316 was made of a lot of tiny cards.)
> > >
> > >> The MBB was "microprogrammable" and so we built the C/70 ...
> Alex/Dave:
> > >> was any of the development of the C70 written up?
> > >
> > > I definitely read a document about the MBB. I have this vague memory
> > that it was
> > > hardcopy, but I doubt I'll be able to locate it anytime soon.
> > >
> > > ISTR that the MBB took a daughtercard, which implemented extra
> > functionality,
> > > and the C/70 took its own; I don't recall exactly what the C/70 one
> did,
> > > though.
> > >
> > >    Noel
> > >
> > > --
> > > Internet-history mailing list
> > > Internet-history at elists.isoc.org
> > > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>

-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190