The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Johnny Billquist <bqt@update.uu.se>
To: Clem cole <clemc@ccc.com>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] core
Date: Sun, 17 Jun 2018 03:50:54 +0200	[thread overview]
Message-ID: <2a35f8dd-e8b8-937a-1af9-d18ac31b8be2@update.uu.se> (raw)
In-Reply-To: <20B7C3F5-2E44-41AB-91E4-510451428C83@ccc.com>

On 2018-06-17 02:15, Clem cole wrote:
> Hmm. I think you are trying to put to fine a point on it.  Having had this conversation with a number of folks who were there, you’re right that the ability to memory on the Unibus at the lower end was clearly there but I’ll take Dave Cane and Henk’s word for it as calling it an IO bus who were the primary HW folks behind a lot of it.  Btw it’s replacement, Dave’s BI, was clearly designed with IO as the primary point. It was supposed to be open sourced in today’s parlance but DEC closed it at the end.  The whole reason was to have an io bus the 3rd parties could build io boards around.  Plus,  By then DEC started doing split transactions on the memory bus ala the SMI which was supposed to be private. After the BI mess,   And then By the time of Alpha BI morphed into PCI which was made open and of course is now Intel’s PCIe.   But that said, even today we need to make large memory windows available thru it for things like messaging and GPUs - so the differences can get really squishy.   OPA2 has a full MMU and can do a lot of cache protocols just because the message HW really looks to memory a whole lot like a CPU core.  And I expect future GPUs to work the same way.

Well, it is an easy observable fact that before the PDP-11/70, all 
PDP-11 models had their memory on the Unibus. So it was not only "an 
ability at the lower end", but the only option for a number of years. 
The need to grow beyond 18 bit addresses, as well as speed demands, 
drove the PDP-11/70 to abandon the Unibus for memory. And this was then 
also the case for the PDP-11/44, PDP-11/24, PDP-11/84 and PDP-11/94, 
which also had 22-bit addressing of memory, which then followed the 
PDP-11/70 in having memory separated from the Unibus. All other Unibus 
machines had the memory on the Unibus.

After Unibus (if we skip Q-bus) you had SBI, which was also used both 
for controllers (well, mostly bus adaptors) and memory, for the 
VAX-11/780. However, evaluation of where the bottleneck was on that 
machine led to the memory being moved away from SBI for the VAX-86x0 
machines. SBI never was used much for any direct controllers, but 
instead you had Unibus adapters, so here the Unibus was used as a pure 
I/O bus.

And BI came after that. (I'm ignoring the CMI of the VAX-11/750 and 
others here...)
By the time of the VAX, the Unibus was clearly only an I/O bus (for VAX 
and high end PDP-11s). No VAX ever had memory on the Unibus. But the 
Unibus was not design with the VAX in mind.

But unless my memory fails me, VAXBI have CPUs, memory and bus adapters 
as the most common kind of devices (or "nodes" as I think they are 
called) on BI. Which really helped when you started doing multiprocessor 
systems, since you then had a shared bus for all memory and CPU 
interconnect. You could also have Unibus adapters on VAXBI, but it was 
never common.

And after VAXBI you got XMI. Which is also what early large Alphas used. 
Also with CPUs, memory and bus adapters. And in XMI machines, you 
usually have VAXBI adapters for peripherals, and of course on an XMI 
machine, you would not hook up CPUs or memory on the VAXBI, so in an XMI 
machine, VAXBI became de facto an I/O bus.

Not sure there is any relationship at all between VAXBI and PCI, by the way.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

  reply	other threads:[~2018-06-17  1:51 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1.1529175600.3826.tuhs@minnie.tuhs.org>
2018-06-16 22:14 ` Johnny Billquist
2018-06-16 22:38   ` Arthur Krewat
2018-06-17  0:15   ` Clem cole
2018-06-17  1:50     ` Johnny Billquist [this message]
2018-06-17 10:33       ` Ronald Natalie
2018-06-20 16:55       ` Paul Winalski
2018-06-20 21:35         ` Johnny Billquist
2018-06-20 22:24           ` Paul Winalski
2018-06-21 22:44 Nelson H. F. Beebe
2018-06-21 23:07 ` Grant Taylor via TUHS
2018-06-21 23:38   ` Toby Thain
  -- strict thread matches above, loose matches on Subject: below --
2018-06-21 17:40 Noel Chiappa
2018-06-21 17:07 Nelson H. F. Beebe
2018-06-21 13:46 Doug McIlroy
2018-06-21 16:13 ` Tim Bradshaw
2018-06-20 20:11 Doug McIlroy
2018-06-20 23:53 ` Tim Bradshaw
2018-06-19 12:23 Noel Chiappa
2018-06-19 12:58 ` Clem Cole
2018-06-19 13:53   ` John P. Linderman
2018-06-21 14:09 ` Paul Winalski
2018-06-19 11:50 Doug McIlroy
     [not found] <20180618121738.98BD118C087@mercury.lcs.mit.edu>
2018-06-18 21:13 ` Johnny Billquist
2018-06-18 17:56 Noel Chiappa
2018-06-18 18:51 ` Clem Cole
2018-06-18 14:51 Noel Chiappa
2018-06-18 14:58 ` Warner Losh
     [not found] <mailman.1.1529287201.13697.tuhs@minnie.tuhs.org>
2018-06-18  5:58 ` Johnny Billquist
2018-06-18 12:39   ` Ronald Natalie
2018-06-17 21:18 Noel Chiappa
2018-06-17 17:58 Noel Chiappa
2018-06-18  9:16 ` Tim Bradshaw
2018-06-18 15:33   ` Tim Bradshaw
2018-06-17 14:36 Noel Chiappa
2018-06-17 15:58 ` Derek Fawcus
2018-06-16 22:57 Noel Chiappa
2018-06-16 13:49 Noel Chiappa
2018-06-16 14:10 ` Clem Cole
2018-06-16 14:34   ` Lawrence Stewart
2018-06-16 15:28     ` Larry McVoy
2018-06-16 14:10 ` Steve Nickolas
2018-06-16 14:13   ` William Pechter
2018-06-16 13:37 Noel Chiappa
2018-06-16 18:59 ` Clem Cole
2018-06-17 12:15 ` Derek Fawcus
2018-06-17 17:33 ` Theodore Y. Ts'o
2018-06-17 19:50   ` Jon Forrest
2018-06-18 14:56   ` Clem Cole
2018-06-18 12:36 ` Tony Finch
2018-06-16 12:58 Doug McIlroy
2018-06-20 11:10 ` Dave Horsfall
2018-06-16 12:51 Noel Chiappa
2018-06-16 13:11 ` Clem cole
2018-06-15 15:25 Noel Chiappa
2018-06-15 23:05 ` Dave Horsfall
2018-06-15 23:22   ` Lyndon Nerenberg
2018-06-16  6:36     ` Dave Horsfall
2018-06-16 19:07       ` Clem Cole
2018-06-18  9:25         ` Tim Bradshaw
2018-06-19 20:45           ` Peter Jeremy
2018-06-19 22:55             ` David Arnold
2018-06-20  5:04               ` Peter Jeremy
2018-06-20  5:41                 ` Warner Losh
2018-06-15 11:19 A. P. Garcia
2018-06-15 13:50 ` Steffen Nurpmeso
2018-06-15 14:21 ` Clem Cole
2018-06-15 15:11   ` John P. Linderman
2018-06-15 15:21     ` Larry McVoy
2018-06-16  1:08   ` Greg 'groggy' Lehey
2018-06-16  2:00     ` Nemo Nusquam
2018-06-16  2:17     ` John P. Linderman
2018-06-16  3:06     ` Clem cole
2018-06-20 10:06 ` Dave Horsfall

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=2a35f8dd-e8b8-937a-1af9-d18ac31b8be2@update.uu.se \
    --to=bqt@update.uu.se \
    --cc=clemc@ccc.com \
    --cc=tuhs@minnie.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).