[ih] NCP and TCP implementations

[vinton cerf]

that makes more sense than running native "C" code!!!

v


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

> Vint,
>
> I wasn't close enough to the C/70 development to really know how it was
> implemented, I was just a user. :-)
>
> I also assume that the C/70 microcode implemented some sort of intermediate
> assembly with built in support for C constructs like procedure calls and
> data structures, but I don't know for sure.
>
> Cheers,
> Andy
>
>
> On Mon, Mar 16, 2020 at 4:59 PM Vint Cerf <vint at google.com> wrote:
>
> > 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
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>