17 Jun
2018
17 Jun
'18
7:50 a.m.
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(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol