The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: ron@ronnatalie.com (Ron Natalie)
Subject: 4.2BSD steering committee members
Date: Sun, 8 Oct 2017 08:51:12 -0400	[thread overview]
Message-ID: <001301d34034$1f70a770$5e51f650$@ronnatalie.com> (raw)
In-Reply-To: <C32FB859-584C-4C03-BD80-594ED889EC3A@planet.nl>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]


* Alan Nemeth - apparently the designer of the BBN C-series mini’s (I think the C30 was designed to replace the 316/516 as IMP). It is hard to find any info on the C-series, but I understand it to be a mini with 10 bit bytes, 20 bit words and 20 bit address space, more or less modeled after the PDP11 and an instruction set optimised to be an easy target for the C compilers of the day. Any other links to Unix?

The C machine was a generic emulation box if I recall properly.   The C-30 was indeed an attempt to emulate the 316/516 for IMPS/TACS.   In BBNs long history of selling the same thing to the government over and over, they tweaked the firmware with the goal of allegedly coming up with the perfect instruction set for running C programs and dubbed that model the C- 70.    I had use of a few in the Army.     They were kind of "meh" processors and frankly, I don't recall them running a BSD-ish version of UNIX.

* Dan Lynch - ISI program manager for TCP/IP and the switch-over from NCP on Arpanet.

And eventually running the Interop TCP/IP promotion organization.

* Gerald Popek - worked on a secure version of (Arpanet enabled) Unix and on distributed systems (LOCUS) at the time.

>  Next to networking, the link between these people seems to have been distributed computing — yet I don’t think 4.2BSD had a goal of being multiprocessor ready.

But it wasn't particularly ill suited for that.    George Gobels had little problem getting the dual-vax running.    We ported 4.2 to the MIMD HEP early on as well.   All of these worked fine as long as you guaranteed that no more than one processor went into the core kernel at one time.     It didn't always need to be the same CPU, but just that you didn't have concurrency.    The HEP and a later product I worked on with four i860 processors, the kernel would bounce around among the different processors.




  reply	other threads:[~2017-10-08 12:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-08 12:42 Paul Ruizendaal
2017-10-08 12:51 ` Ron Natalie [this message]
2017-10-09 20:47 ` Jeremy C. Reed
2017-10-08 15:16 Noel Chiappa
2017-10-15  8:44 Paul Ruizendaal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001301d34034$1f70a770$5e51f650$@ronnatalie.com' \
    --to=ron@ronnatalie.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).