The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] PDP-11 questions
Date: Sun, 24 Jan 2016 13:01:40 -0500 (EST)	[thread overview]
Message-ID: <20160124180140.9986B18C0A4@mercury.lcs.mit.edu> (raw)

    > From: Mark Longridge

    > when Bell Labs got that first PDP-11/20 what software (if any) came
    > with it?

I have this bit set that they didn't get anything, they wrote a
cross-assembler on another machine. I know that when it came, it didn't have a
disk (wasn't ready yet), so it ran a chess problem (memory only) for quite a
while until the disk came. I think that's in the ACM paper, or if not, one of
the BSTJ Unix history papers.


    > Perhaps an older PDP-11 doesn't have DRAM but surely the later models
    > did?

MOS memory came in starting roughly around the time of the 11/04 and /34.
(Well, that's not quire right - there were bipolar and MOS memory options
for the 11/45, the second PDP-11 model, but they were kind of special.)

But the earliest ROM bootstraps were too small to have space for code to
clear memory, or anything like that. The diode-array BM792 ROM certainly
didn't.

The later M9301 (see disassembly of the contents here:

  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/M9301-YA.mac

of one variant) didn't clear memory either, although there was probably room
in the ROMs by that point.

I suspect it didn't because nobody bothered with stuff like that back then -
you just wrote over whatever was already there. Properly written code would
never have referenced a location which had not been loaded or written to, that
way you couldn't get a parity error from random gubbish in semi-conductor at
power up (and of course core always had old data in it).


    > Now the last question has to do with what made the PDP-11 architecture
    > so great.

Bang/buck (in the metaphorical sense) ratio.

For a machine with a 16-bit word size (i.e. limited instruction size), it had
remarkable programming capability. Data could be in registers, pushed or
popped with a stack, at fixed addresses, PC-relative, indexed into a table,
etc, etc. And _all_ the instructions (basically) had acceess to _all_ those
modes.

As a result, the code density was probably higher than any similar sized
machine, and back when memory was core (i.e. expensive/limited), code density
was important.

The bus was also extremely flexible, given how simple it was: memory and
devices were all on the same (simple) bus.

    > of course it was the machine that made Unix possible

I'd lay good money that the vast majority of PDP-11's never ran Unix. And
UNIX might have happened on some other machine - it's not crucially tied to
the PDP-11 - in fact, the ease with which it could be used on other machines
was a huge part of its eventual success.

    > It seems though that there should have been a PDP-11 based desktop and
    > as far as I can tell that didn't happen.

Because DEC were a bunch of losers. There's some DEC history book which talks
about DEC's multiple failures (on a variety of platforms, not just PDP-11
based ones) to get into the desktop market, if the title comes to me, I'll
post it.

	Noel


             reply	other threads:[~2016-01-24 18:01 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-24 18:01 Noel Chiappa [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-01-26 20:07 Doug McIlroy
2016-01-26 20:44 ` Clem Cole
2016-01-26 19:36 Doug McIlroy
2016-01-26 19:59 ` Warren Toomey
     [not found] <mailman.29.1453684304.15972.tuhs@minnie.tuhs.org>
2016-01-25  3:07 ` Johnny Billquist
2016-01-25  3:09 ` Johnny Billquist
2016-01-25 12:54   ` John Cowan
2016-01-25 13:09     ` Johnny Billquist
2016-01-25 13:49     ` Johnny Billquist
2016-01-25 16:00       ` John Cowan
2016-01-25 16:17         ` Johnny Billquist
2016-01-25 16:43           ` John Cowan
2016-01-25  1:11 Noel Chiappa
2016-01-25  1:30 ` Clem cole
2016-01-24 22:40 Norman Wilson
2016-01-25  1:55 ` David Ritchie
2016-01-25  1:59   ` Ronald Natalie
2016-01-25  2:14   ` Clem cole
2016-01-25 11:29 ` Tony Finch
2016-01-25 13:25   ` Ronald Natalie
2016-01-25 16:18   ` Pete Turnbull
2016-01-25 19:37     ` Clem Cole
2016-01-24 22:40 Norman Wilson
2016-01-25  0:23 ` Ronald Natalie
2016-01-24 18:56 Noel Chiappa
     [not found] <mailman.25.1453658502.15972.tuhs@minnie.tuhs.org>
2016-01-24 18:34 ` Johnny Billquist
2016-01-24 18:30 Noel Chiappa
2016-01-24 18:36 ` Ronald Natalie
2016-01-24 21:10   ` John Cowan
2016-01-25  0:11 ` scj
2016-01-25  0:36   ` Clem cole
2016-01-24 17:37 Mark Longridge
2016-01-24 18:49 ` Clem Cole
2016-01-25  3:16   ` Dave Horsfall
2016-01-25  5:32     ` Warren Toomey
2016-01-25 12:27       ` Clem cole
2016-01-25 13:38         ` Lawrence Stewart
2016-01-25 14:15           ` Clem Cole
2016-01-26 19:52         ` Dave Horsfall
2016-01-26 20:41           ` Clem Cole

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=20160124180140.9986B18C0A4@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    /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).