The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Ron Natalie" <ron@ronnatalie.com>
To: tuhs@tuhs.org
Subject: [TUHS] First supercomputer UNIX: The Denelcor HEP (was Early multiprocessor Unix)
Date: Tue, 29 Nov 2022 15:54:45 +0000	[thread overview]
Message-ID: <em64d7f56c-54af-4263-92ec-4795bbfb21cc@c62ead55.com> (raw)
In-Reply-To: <Y4XTYx+Kf1wY/Ux6@largo.jsg.id.au>

In 1982, I returned to BRL (having spent a year working for Martin 
Marietta on  project involving a dual process RSX-11M system.    I did 
spend some time setting up the PWB UNIX tools with the QA guys while 
there).

BRL had commissioned the Denver Electronics Corporation (i.e., Denelcor) 
to build a MIMD system called the HEP, ostensibly to do fluid dynamics 
problems.   It was looking like the manufacturer wasn’t going to have a 
useful OS for it so Mike Muss did his usual thing and suggested he could 
put UNIX on it (he had done this twice previously with orphaned 
machines:  some 11/34 graphics stations that were supposed to be 
connected to the CDC7600 and converting the University of Illinois 
Arpanet Terminal Server (ANTS) to a host that could support long 
leaders.

I was part of Mike’s team.   We split up various aspects of the project. 
   Mike ported PCC.   I ported ld, and F77 (as we figured the 
“scientists” would probably want that).    Mike did the core of the 
kernel.  I handled all the I/O system because I was the “device driver” 
guy at JHU and continued on with this at BRL.     Our initial work was 
done by traveling out to Denelcor’s facility where our machine was 
assembled on their floor.   They had started their operating system work 
(not UNIX), so we took the machine after hours.   Amusingly, at BRL in 
the room the HEP was going in, the cabinet layout was taped out on the 
floor around a central pillar.   The tape marked with the component that 
went there.   Out in the Denver machine room, the equipment was there 
but there was a square taped out that said “BRL post” so they knew not 
to put/route anything there.

The software being ported was 4BSD.    I believe we started with the 
George Gobels mods of the dual VAX (BRL already had built one of these). 
   In working on that I found there was a rather serious portability 
problem.    The kernel did what I refer to as “conversion by union” 
where they stuck a pointer of one type into one element of the union and 
retrieved it by a different pointer type union element.   Well, such is 
all well and good on the VAX, but the HEP encoded the partial word size 
into the low order bits of the pointer.   This meant that you ended up 
with pointers that would access the wrong size operand.    I spent a few 
days chasing down all these things and fixing them.

The HEP had an 11/34 as a control processor that allowed you to 
configure the switch system that interconnected the memory in the 
processors.    It did this via a special feature called (aptly) “The Low 
Speed Bus” (more on that later).   But once running, everything was self 
contained on the HEP hardware itself.    Other amusing things about the 
HEP is it had a lot of registers.   It also had this stuff called “table 
memory” which essentially were read-only registers.  You could but a 
variety of constants there (we had all the integers from 0-255 and then 
powers of two after that).    The rest of the memory had an extra bit 
per 64-bit word called the “full empty” bit.   While the thing was 
capable of running the equivalent of 32 UNIX processes simultaneously, 
it also had the ability within each of those to hardware schedule 
threads.  Many instructions had features that used the extra bit like 
“WAIT FULL, READ, SET EMPTY” or “WRITE, SET FULL”.

The whole thing was built out of Motorola 10800 ECL.   All hand 
assembled.   Quite impressive.

After we got the system up, and Mike tried to port his ray tracing 
software to it, we found the I/O system was beastly slow.  The I/O 
system was a cute device.  It had a bunch traditional memory (no 
full/empty bits) connected to the main memory via the switch but also to 
32 individual UNIBUSes.   The only problem was that in order to whack 
the registers on the UNIBUS you had to do it through the “Low Speed 
Bus.”    This was the performance bottleneck.    The original designer 
of this thing, Burton Smith and I sat down at the Golden Corral 
Steakhouse in Aberdeen and worked on a new plan.   The key was to allow 
the kernel tasks to talk directly to the UNIBUS registers via the 
regular memory switch.    Fortunately, we had an extra switch node in 
spare parts.    We did however need software and another PDP-11 to 
control the thing.   Fortunately, I had spares from my building of the 
early internet router: BRL-GATEWAY.   I also used the little OS on it 
(LOS) to write the control software.   In a couple of days, we had 
rebuilt the I/O system out of essentially spare parts and it flew.

Amusingly, this was the first of two UNIX ports I worked on that didn’t 
use the standard ISR thing that most of the kernels those days did.    
After the device driver on the HEP had started the IO up, that thread 
just ended.    When the UNIBUS interrupt came in, a new thread was 
created to service it.    I later did a similar strategy with the 
message passing coprocessor on the Multibus II.

This was a fun waste of about a year.    By the time we got this ready 
for prime time, the Army had decided they didn’t have any supercomputers 
(other than HEP) and immediately used defense priority to snag the next 
Cray X/MP off the assembly line (which had been slated for Apple).    
Mike got one run of his raytracer to make a movie:  The artillery 
shell’s view of collision with a tank.   The HEP could generate the 
frames about 60:1 (took a minute to make one second of movie time) 
faster than anything else we had in the day.    Of course, it pales 
compared to your modern video games.   After that, the HEP was 
dismantled (Denelcor had gone out of business) to make room for the 
Cray.   I recently just found pictures of us all sitting on the “seats” 
of the Cray and one of me peering out from the core of the machine.

The Army went on for plans for multiple Cray 2 purchases.   After a lot 
of amusing “systems engineering” work that originally slated for all of 
them to go in Oak Ridge Tennessee, and then all of them to go at BRL, 
they decided to spread them around the country (what I told them they 
should do in the first place).    My last months at BRL, I signed my 
name to the $25 million dollar Cray 2 procurement, but it got delivered 
after I left (I visited it a few years later).

Somewhere I still have the name plates for the Denelcor HEP H1000.   
They, in fact, were never actually installed on the machine,


  reply	other threads:[~2022-11-29 15:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 13:24 [TUHS] Early multiprocessor Unix Paul Ruizendaal
2022-11-28 13:42 ` [TUHS] " Larry Stewart
2022-11-28 14:05 ` Clem Cole
2022-11-28 14:13   ` Clem Cole
2022-11-28 14:19     ` Warner Losh
2023-08-06 14:19     ` Warner Losh
2022-11-28 14:16   ` Warner Losh
2022-11-28 14:50     ` Clem Cole
2022-11-28 16:30   ` Paul Winalski
2022-11-28 16:49     ` Clem Cole
2023-08-06 14:12   ` Warner Losh
2022-11-28 16:52 ` Jonathan Gray
2022-11-29  9:39 ` Jonathan Gray
2022-11-29 15:54   ` Ron Natalie [this message]
2022-11-29 17:00     ` [TUHS] Re: First supercomputer UNIX: The Denelcor HEP (was Early multiprocessor Unix) Jon Steinhart
2022-11-29 20:53     ` steve jenkin
2023-08-05 23:00 ` [TUHS] Re: Early multiprocessor Unix scj
2023-08-06  0:54   ` Larry McVoy
2023-08-06  6:52   ` Paul Ruizendaal
2023-08-06  9:28   ` Ronald Natalie
2023-08-06  9:57   ` Ralph Corderoy

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=em64d7f56c-54af-4263-92ec-4795bbfb21cc@c62ead55.com \
    --to=ron@ronnatalie.com \
    --cc=tuhs@tuhs.org \
    /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).