The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
To: Paul Ruizendaal <>
Cc: The Eunuchs Hysterical Society <>
Subject: [TUHS] Re: Early multiprocessor Unix
Date: Sat, 05 Aug 2023 16:00:55 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

When I left Bell Labs in 1986, I joined Ardent Computer in California.  
We built a multiprocessor Unix system with up to four processors based 
on ECL technology (faster than the computer chips of the time).  The CPU 
had a standard set of registers, and there were four vector registers 
that would hold 1000 floating-point numbers and vector instructions to 
do arithmetic.
So that meant that we had compiler work to do.  Luckily, Randy Allen had 
just graduated and signed on to do the parallelism.  I took on the job 
of doing the assembler, loader, parallelizing C and FORTRAN compilers, 
and I did the lower-level stuff: assembler, loader,
designed the a.out format, and even wrote a bug tracking system.  
Randy's compiler was excellent, but there were other problems.  The Sun 
workstations had some quirks: from time to time they would page in a 
page of all zeros due to a timing problem.  Unhappily, the zero was the 
halt operation!  We addressed that by adding code to the Kernel the 
verify that no code page was all 0's before executing.   AT&T and Sun 
and MIPS and all the hardware makers have problems like this with early 
chips.  One thing I had told the team from the beginning was that we 
were going to have to patch hardware problems in the early versions.

The most serious early hardware bug in our machine was that when the 
MIPS chip had a page fault, the CPU started executing the new page 
before it was all present.  It only missed the first two or three 
instructions.  We settled on a strategy to generate the a.out file so 
that the first 4 instructions were all No-Ops.  This solved the MIPS 

Now we faced the problem of how do we take a standard a.out format and 
redo it so that the first four instructions in each code page are NOPs.  
We built an "editor" for a.out files that would read the file in, 
respond to a series of requests, relocate the instructions correctly, 
and then branch to the line of code that it had been about to execute.  
One good thing about this was that when the chip got fixed we would not 
have to change any code -- it would just work.

And then we got creative.  We could use the "editor" to find the basic 
blocks in the code, introduce counting instructions at the head of each 
block, and produce a profiler by recompiling.  We probably found about 
20 things we could do with this mechanism, including optimization after 
loading, timing the code without having to recompile everything, 
collecting parallelism statistics, etc.


On 2022-11-28 05:24, Paul Ruizendaal wrote:
> The discussion about the 3B2 triggered another question in my head:
> what were the earliest multi-processor versions of Unix and how did
> they relate?
> My current understanding is that the earliest one is a dual-CPU VAX
> system with a modified 4BSD done at Purdue. This would have been late
> 1981, early 1982. I think one CPU was acting as master and had
> exclusive kernel access, the other CPU would only run user mode code.
> Then I understand that Keith Kelleman spent a lot of effort to make
> Unix run on the 3B2 in a SMP setup, essentially going through the
> source and finding all critical sections and surrounding those with
> spinlocks. This would be around 1983, and became part of SVr3. I
> suppose that the “spl()” calls only protected critical sections that
> were shared between the main thread and interrupt sequences, so that a
> manual review was necessary to consider each kernel data structure for
> parallel access issues in the case of 2 CPU’s.
> Any other notable work in this area prior to 1985?
> How was the SMP implementation in SVr3 judged back in its day?
> Paul

  parent reply	other threads:[~2023-08-05 23:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 13:24 [TUHS] " 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   ` [TUHS] First supercomputer UNIX: The Denelcor HEP (was Early multiprocessor Unix) Ron Natalie
2022-11-29 17:00     ` [TUHS] " Jon Steinhart
2022-11-29 20:53     ` steve jenkin
2023-08-05 23:00 ` scj [this message]
2023-08-06  0:54   ` [TUHS] Re: Early multiprocessor Unix Larry McVoy
2023-08-06  6:52   ` Paul Ruizendaal
2023-08-06  9:28   ` Ronald Natalie
2023-08-06  9:57   ` Ralph Corderoy
2022-11-30  2:55 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:

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

  git send-email \ \ \ \ \

* 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).