16 Jun
2018
16 Jun
'18
10:14 p.m.
On 2018-06-16 21:00, Clem Cole <clemc(a)ccc.com> wrote:
I think the paper you both are referring to is the "What have we learned
from the PDP-11", by Gordon Bell and Bill Strecker in 1977.
https://gordonbell.azurewebsites.net/Digital/Bell_Strecker_What_we%20_learn…
There is some additional comments in
https://gordonbell.azurewebsites.net/Digital/Bell_Retrospective_PDP11_paper…
below... > On Sat, Jun 16, 2018 at 9:37 AM, Noel
Chiappa
<jnc(a)mercury.lcs.mit.edu> wrote:
Let's start with the UNIBUS. Why does it have only 18 address lines? (I
have
this vague memory of a quote from Gordon Bell admitting that was a mistake,
but I don't recall exactly where I saw it.)
I think it was part of the same
paper where he made the observation that
the greatest mistake an architecture can have is too few address bits. My understanding is that the problem was that UNIBUS
was perceived as an
I/O bus and as I was pointing out, the folks creating it/running the team
did not value it, so in the name of 'cost', more bits was not considered
important.
Hmm. I'm not aware of anyone perceiving the Unibus as an I/O bus. It was
very clearly designed a the system bus for all needs by DEC, and was
used just like that until the 11/70, which introduced a separate memory
bus. In all previous PDP-11s, both memory and peripherals were connected
on the Unibus.
Why it only have 18 bits, I don't know. It might have been a reflection
back on that most things at DEC was either 12 or 18 bits at the time,
and 12 was obviously not going to cut it. But that is pure speculation
on my part.
But, if you read that paper again (the one from Bell), you'll see that
he was pretty much a source for the Unibus as well, and the whole idea
of having it for both memory and peripherals. But that do not tell us
anything about why it got 18 bits. It also, incidentally have 18 data
bits, but that is mostly ignored by all systems. I believe the KS-10
made use of that, though. And maybe the PDP-15. And I suspect the same
would be true for the address bits. But neither system was probably
involved when the Unibus was created, but made fortuitous use of it when
they were designed.
I used to know and work with the late Henk Schalke,
who ran Unibus (HW)
engineering at DEC for many years. Henk was notoriously frugal (we might
even say 'cheap'), so I can imagine that he did not want to spend on
anything that he thought was wasteful. Just like I retold the
Amdahl/Brooks story of the 8-bit byte and Amdahl thinking Brooks was nuts;
I don't know for sure, but I can see that without someone really arguing
with Henk as to why 18 bits was not 'good enough.' I can imagine the
conversation going something like: Someone like me saying: *"Henk, 18 bits
is not going to cut it."* He might have replied something like: *"Bool
sheet *[a dutchman's way of cursing in English], *we already gave you two
more bit than you can address* (actually he'd then probably stop mid
sentence and translate in his head from Dutch to English - which was always
interesting when you argued with him).
Quite possible. :-)
Note: I'm not blaming Henk, just stating that his
thinking was very much
that way, and I suspect he was not not alone. Only someone like Gordon and
the time could have overruled it, and I don't think the problems were
foreseen as Noel notes.
Bell in retrospect thinks that they should have realized this problem,
but it would appear they really did not consider it at the time. Or
maybe just didn't believe in what they predicted.
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
16 Jun
16 Jun
10:38 p.m.
New subject: core
On 6/16/2018 6:14 PM, Johnny Billquist wrote:
I believe the KS-10 made use of that, though.
Absolutely.
The 36-bit transfer mode requires one memory cycle
(rather than two) for each word transferred. In 36-bit
mode, the PDP-11 word count must be even (an odd word count
would hang the UBA) . Only one device on each UBA can do
36-bit transfers; this is because the UBA has only one
buffer to hold the left 18 bits, while the right 18 bits
come across the UNIBUS. On the 2020 system, the disk is the
only device using the 36-bit transfer mode.
17 Jun
17 Jun
12:15 a.m.
New subject: core
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.
And at this point (on die) the differences between a memory and io bus are often driven by
power and die size. The Memory bus folks are often willing to pay more to keep the memory
heiarchary a bit more sane. IO busses will often let the SW deal with consistency in
return for massive scale.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
On Jun 16, 2018, at 6:14 PM, Johnny Billquist
<bqt(a)update.uu.se> wrote:
I think the paper you both are referring to is the "What have we learned from the
PDP-11", by Gordon Bell and Bill Strecker in 1977.
https://gordonbell.azurewebsites.net/Digital/Bell_Strecker_What_we%20_learn…
There is some additional comments in
https://gordonbell.azurewebsites.net/Digital/Bell_Retrospective_PDP11_paper…
On 2018-06-16 21:00, Clem Cole
<clemc(a)ccc.com> wrote:
below... > On Sat, Jun 16, 2018 at 9:37 AM, Noel Chiappa
<jnc(a)mercury.lcs.mit.edu> wrote:
Let's start with the UNIBUS. Why does it have only 18 address lines? (I
have
this vague memory of a quote from Gordon Bell admitting that was a mistake,
but I don't recall exactly where I saw it.)
I think it was part of the same
paper where he made the observation that
the greatest mistake an architecture can have is too few address bits. My understanding is that the problem was that
UNIBUS was perceived as an
I/O bus and as I was pointing out, the folks creating it/running the team
did not value it, so in the name of 'cost', more bits was not considered
important.
Hmm. I'm not aware of anyone perceiving the Unibus as an I/O bus. It was very
clearly designed a the system bus for all needs by DEC, and was used just like that until
the 11/70, which introduced a separate memory bus. In all previous PDP-11s, both memory
and peripherals were connected on the Unibus.
Why it only have 18 bits, I don't know. It might have been a reflection back on that
most things at DEC was either 12 or 18 bits at the time, and 12 was obviously not going to
cut it. But that is pure speculation on my part.
But, if you read that paper again (the one from Bell), you'll see that he was pretty
much a source for the Unibus as well, and the whole idea of having it for both memory and
peripherals. But that do not tell us anything about why it got 18 bits. It also,
incidentally have 18 data bits, but that is mostly ignored by all systems. I believe the
KS-10 made use of that, though. And maybe the PDP-15. And I suspect the same would be true
for the address bits. But neither system was probably involved when the Unibus was
created, but made fortuitous use of it when they were designed.
I used to know and work with the late Henk
Schalke, who ran Unibus (HW)
engineering at DEC for many years. Henk was notoriously frugal (we might
even say 'cheap'), so I can imagine that he did not want to spend on
anything that he thought was wasteful. Just like I retold the
Amdahl/Brooks story of the 8-bit byte and Amdahl thinking Brooks was nuts;
I don't know for sure, but I can see that without someone really arguing
with Henk as to why 18 bits was not 'good enough.' I can imagine the
conversation going something like: Someone like me saying: *"Henk, 18 bits
is not going to cut it."* He might have replied something like: *"Bool
sheet *[a dutchman's way of cursing in English], *we already gave you two
more bit than you can address* (actually he'd then probably stop mid
sentence and translate in his head from Dutch to English - which was always
interesting when you argued with him).
Quite possible. :-)
Note: I'm not blaming Henk, just stating
that his thinking was very much
that way, and I suspect he was not not alone. Only someone like Gordon and
the time could have overruled it, and I don't think the problems were
foreseen as Noel notes.
Bell in retrospect thinks that they should have realized this problem, but it would
appear they really did not consider it at the time. Or maybe just didn't believe in
what they predicted.
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
1:50 a.m.
New subject: core
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
10:33 a.m.
New subject: core
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", b
That’s not quite true. While the 18 bit addressed machines all had their memory directly
accessible from the Unibus, the 45/50/55 had a separate bus for the (then new)
semiconductor (bipolar or MOS) memory.
20 Jun
20 Jun
4:55 p.m.
New subject: core
On 6/16/18, Johnny Billquist <bqt(a)update.uu.se> wrote:
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.
You forgot the Massbus--commonly used for disk I/O.
SBI on the 11/780 connected the CPU (CPUs, for the 11/782), memory
controller, Unibus controllers, Massbus controllers, and CI
controller.
CI (computer interconnect) was the communications medium for
VAXclusters (including the HSC50 intelligent disk controller).
DEC later introduced another interconnect system called BI, intended
to replace Unibus and Massbus.
As we used to say in our software group about all the various busses
and interconnects:
E Unibus Plurum
-Paul W.
9:35 p.m.
New subject: core
On 2018-06-20 18:55, Paul Winalski wrote:
On 6/16/18, Johnny Billquist <bqt(a)update.uu.se>
wrote:
I didn't try for pure I/O buses. But yes, the Massbus certainly also
existed.
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.
You forgot the Massbus--commonly used for disk I/O. SBI on the 11/780 connected the CPU (CPUs, for the
11/782), memory
controller, Unibus controllers, Massbus controllers, and CI
controller.
Right.
CI (computer interconnect) was the communications
medium for
VAXclusters (including the HSC50 intelligent disk controller).
But CI I wouldn't even call a bus.
DEC later introduced another interconnect system
called BI, intended
to replace Unibus and Massbus.
I think that is where my comment started.
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
10:24 p.m.
New subject: core
On 6/20/18, Johnny Billquist <bqt(a)update.uu.se> wrote:
You're right--it's a high-speed point-to-point communications network
with a star topology.
-Paul W.
CI (computer interconnect) was the communications
medium for
VAXclusters (including the HSC50 intelligent disk controller).
But CI I wouldn't even call a bus.
2138
days inactive
2142
days old
7 comments
5 participants
participants (5)
-
Arthur Krewat -
Clem cole -
Johnny Billquist -
Paul Winalski -
Ronald Natalie