The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem cole <clemc@ccc.com>
To: Johnny Billquist <bqt@update.uu.se>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] core
Date: Sat, 16 Jun 2018 20:15:14 -0400	[thread overview]
Message-ID: <20B7C3F5-2E44-41AB-91E4-510451428C83@ccc.com> (raw)
In-Reply-To: <86dcd19d-f805-f338-f190-ab38d1ac82c1@update.uu.se>

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@update.uu.se> wrote:
> 
>> On 2018-06-16 21:00, Clem Cole <clemc@ccc.com> wrote:
>> below... > On Sat, Jun 16, 2018 at 9:37 AM, Noel Chiappa 
> <jnc@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.​
> 
> 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_learned_fm_PDP-11c%207511.pdf
> 
> There is some additional comments in https://gordonbell.azurewebsites.net/Digital/Bell_Retrospective_PDP11_paper_c1998.htm
> 
>>  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@softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol

  parent reply	other threads:[~2018-06-17  0:15 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 [this message]
2018-06-17  1:50     ` Johnny Billquist
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=20B7C3F5-2E44-41AB-91E4-510451428C83@ccc.com \
    --to=clemc@ccc.com \
    --cc=bqt@update.uu.se \
    --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).