The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: ron@ronnatalie.com (Ron Natalie)
Subject: [TUHS] lost ports
Date: Wed, 4 Jan 2017 16:41:07 -0500	[thread overview]
Message-ID: <01c001d266d3$42294820$c67bd860$@ronnatalie.com> (raw)
In-Reply-To: <CAP6exYLat4Xucfj7V99Ev8SeA8jV3NDA7axia6Ta=k+mr62Kiw@mail.gmail.com>

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

I worked a lot on the Gould SEL machines.    I believe they copted George Goble from Purdue and some of his gang to do a lot of the initial OS work as the machines were dual processors and George had done the multiprocessor kernel for his “dual VAX” hack.

 

We met with the project leading vice president, Jim Clark when they were planning this and really drove them torwards a BSD based kernel.     His eyes lit up when we told him of Doug Gwyn’s SV on BSD dist which seaeled the deal.    Amusingly, the SEL UNIX didn’t put a memory page at location zero by default.    This should have been fine.    In the PDP-11 kernel, location zero usually held the first few instructions of the program (notably a setd instruction and a few others that would cause printf(“%s”, 0) to print p&P6).   The VAX BSD kernel put a zero at location zero which allowed all sorts of bugs to hide.       We didn’t really mind the SEL behavior until we found a few programs that we didn’t have source code for crashing (notably Oracle).    We had to put a hack in that if the a.out had a non-zero value in one of the unused fields it would put it in to “braindamaged VAX compatilibilty mode” mapping a zero at zero.    This allowed us to poke the afflicted binaries.    

 

Years later a friend of mine was saying…here’s something you don’t see every day…a black computer company VP.   I pointed out that I had worked with Jim Clark at Gould so there must be at least two.    Turns out the article he was reading was about Jim joining AT&T.   He’s still around somewhere (he’s on the board of the EAA right now).   He might be a good guy to invite to the list.

 

The BBN C machines were indeed potentially 20 bits.   They were designed to be a generic hardware emulator, specifically to replace the Honeywell 516s that were being used for IMPS and TIPS at the time.    They then sold someone (DARPA I suspect) the idea that they could write an instrution set that would be ideal for the C language and UNIX.     I’m pretty sure that it was only doing 16 bit operations rather than 20.   If I recall properly the systems were kind of klunky in practice.   The Army had a few of them around.    I never heard the 5 4-bit modules fit into a rack.  The thing was pretty  monolithic looking (about 3’ of 19” rack) and not modular at all.

 

I did kernel work on the PA for HP also worked on their X server (did a few other X servers over the years).

 

The hard part would be finding anybody from these companies who could even remember they made computers let alone had  UNIX software.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170104/66dc58f6/attachment-0001.html>


  reply	other threads:[~2017-01-04 21:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-04 21:24 ron minnich
2017-01-04 21:41 ` Ron Natalie [this message]
2017-01-04 21:58 ` Larry McVoy
2017-01-05  1:52   ` Larry McVoy
2017-01-04 22:01 ` Robert Swierczek
2017-01-04 22:01 ` Dan Cross
2017-01-05 16:01 ` Clem Cole
2017-01-05 16:20   ` Clem Cole
2017-01-05 17:23   ` ron minnich
2017-01-05 19:08     ` Clem Cole
2017-01-05 19:16       ` ron minnich
2017-01-05 20:08         ` Clem Cole
     [not found]           ` <E3DA30C5-7227-4143-8DA1-401A161C74C6@gmail.com>
     [not found]             ` <CAP6exYLvXvtGEWSg_t5bqjJwunGKC1xiiaoLj7yb5QxkHsMvuA@mail.gmail.com>
2017-01-05 23:40               ` Lawrence Stewart
2017-01-05 16:15 ` Derek Fawcus
2017-01-05 18:34   ` Pierre DAVID
2017-01-05 12:28 Rudi Blom

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='01c001d266d3$42294820$c67bd860$@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).