The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] /dev/drum
Date: Sat, 28 Apr 2018 16:40:08 -0400 (EDT)	[thread overview]
Message-ID: <20180428204008.5D76D18C094@mercury.lcs.mit.edu> (raw)

    > From: Johnny Billquist

    > Gah. If I were to try and collect every copy made, it would be quite a
    > collection.

Well, just the 'processor handbook's (the little paperback things), I have
about 30. (If you add devices, that probably doubles it.) I think my
collection is complete.


    > So there was a total change in terminology early in the 11/45 life, it
    > would appear. I wonder why. ... I probably would not blame some market
    > droids.

I was joking, but also serious. I really do think it was most likely
marketing-driven. (See below for why I don't think it was engineering-driven,
which leaves....)

I wonder if there's anything in the DEC archives (a big chunk of which are now
at the CHM) which would shed any light? Some of the archives are online there,
e.g.:

  http://www.bitsavers.org/pdf/dec/pdp11/memos/

but it seems to be mostly engineering (although there's some that would be
characterized as marketing).


    > one of the most important differences between segmentation and pages are
    > that with segmentation you only have one contiguous range of memory,
    > described by a base and a length register. This will be a contiguous
    > range of memory both in virtual memory, and in physical memory.

I agree completely (although I extend it to multiple segments, each of which
has the characterstics you describe).

Which is why I think the original DEC nomenclature for the PDP-11's memory
management was more appropriate - the description above is _exactly_ the
functionality provided for each of the 8 'chunks' (to temporarily use a
neutral term) of PDP-11 address space, which don't quack like most other
'pages' (to use the 'if it quacks like a duck' standard).


One query I have comes from the usual goal of 'virtual memory' (which is the
concept most tightly associated with 'pages'), which is to allow a process to
run without all of its pages in physical memory.

I don't know much about PDP-11 DEC OS's, but do any of them do this? (I.e.
allow partial residency.)  If not, that would be ironic (in view of the later
name) - and, I think, evidence that the PDP-11 'chunks' aren't really pages.


BTW, did you know that prior to the -11/45, there was a memory management
device for the PDP-11 which provided 'real' paging, the KT11-B? More here:

  http://gunkies.org/wiki/KT11-B_Paging_Option

I seem to recall some memos in the memo archive that discussed it; I _think_
it mentioned why they decided not to go that way in doing memory management
for the /45, but I forget the details? (Maybe the performance hit of keeping
the page tables in main memory was significant?)_


    > With segmentation you cannot have your virtual memory split up and
    > spread out over physical memory.

Err, Multics did that; the process' address space was split up into many
segments (a true 2-dimensional naming system, with 18 bits of segment number),
which were then split up into pages, for both virtual memory ('not all
resident'), and for physical memory allocation.

Although I suppose one could view that as two separate, sequential steps -
i.e. i) the division into segments, and ii) the division of segments into
pages. In fact, I take this approach in describing the Multics memory system,
since it's easier to understand as two independent things.

    > You can also have "holes" in your memory, with pages that are invalid,
    > yet have pages higher up in your memory .. Something that is impossible
    > with segmentation, since you only have one set of registers for each
    > memory type (at most) in a segmented memory implementation.

You seem to be thinking of segmentation a la Intel 8086, which is a hack they
added to allow use of more memory (although I suspect that PDP-11 chunks were
a hack of a similar flavour).

At the time we are speaking of, the Intel 8086 did not exist (it came along
quite few years later). The systems which supported segmentation, such as
Multics, the Burroughs 5000 and successors, etc had 'real' segmentation, with
a full two-dimensional naming system for memory. (Burroughs 5000 segment
numbers were 10 bits wide.)

    > I mean, when people talk about segmented memory, what most everyone
    > today thinks of is the x86 model, where all of this certainly is true.

It's also (IMNSHO) irrelevant to this. Intel's brain-damage is not the
entirety of computer science (or shouldn't be).

(BTW, later Intel xx86 machines did allow you have to 'holes' in segments, via
the per-segment page tables.)


    > it would be very wrong to call what the PDP-11 have segmentation

The problem is that what PDP-11 memory management does isn't really like
_either_ segmentation, or paging, as practised in other machines. With only 8
chunks, it's not like Multics etc, which have very large address spaces split
up into many segments. (And maybe _that_'s why the name was changed - when
people heard 'segments' they thought 'lots of them'.)

However, it's not like paging on effectively all other systems with paging,
because in them paging's used to provide virtual memory (in the sense of 'the
process runs with pages missing from real memory'), and to make memory
allocation simple by use of fixed-size page frames.

So any name given PDP-11 'chunks' is going to have _some_ problems. It just
thing 'segmentation' (as you defined it at the top) is a better fit than the
alternative...

   Noel


             reply	other threads:[~2018-04-28 20:40 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-28 20:40 Noel Chiappa [this message]
2018-04-29 15:37 ` Johnny Billquist
2018-04-29 16:34   ` Steve Nickolas
2018-04-29 16:48     ` Warner Losh
     [not found] <mailman.1.1525744802.16322.tuhs@minnie.tuhs.org>
2018-05-08 22:39 ` Johnny Billquist
  -- strict thread matches above, loose matches on Subject: below --
2018-05-07 15:36 Noel Chiappa
2018-05-06 13:07 Noel Chiappa
2018-05-06 15:57 ` Johnny Billquist
2018-05-05 13:06 Noel Chiappa
2018-05-05 20:53 ` Johnny Billquist
2018-05-03 11:39 Noel Chiappa
2018-05-03 21:22 ` Johnny Billquist
2018-04-30 15:05 Noel Chiappa
2018-04-30 16:43 ` Paul Winalski
2018-04-30 21:41 ` Johnny Billquist
2018-05-03  2:54 ` Charles Anthony
2018-04-28  0:19 Noel Chiappa
2018-04-28 10:41 ` Johnny Billquist
2018-04-28 12:19   ` Rico Pajarola
2018-04-27 23:01 Noel Chiappa
2018-04-27 23:10 ` Johnny Billquist
2018-04-27 23:39   ` Warner Losh
     [not found] <mailman.1.1524708001.6296.tuhs@minnie.tuhs.org>
2018-04-27 22:41 ` Johnny Billquist
2018-04-26  1:53 Noel Chiappa
     [not found] <mailman.143.1524696952.3788.tuhs@minnie.tuhs.org>
2018-04-25 23:08 ` Johnny Billquist
2018-04-25 22:55 Noel Chiappa
     [not found] <mailman.139.1524690859.3788.tuhs@minnie.tuhs.org>
2018-04-25 22:54 ` Johnny Billquist
2018-04-25 22:46 Noel Chiappa
     [not found] <mailman.137.1524667148.3788.tuhs@minnie.tuhs.org>
2018-04-25 21:43 ` Johnny Billquist
2018-04-25 22:24 ` Johnny Billquist
2018-04-26  5:51   ` Tom Ivar Helbekkmo
2018-04-25 22:37 ` Johnny Billquist
2018-04-24  7:10 Rudi Blom
     [not found] <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
2018-04-23 23:44 ` Johnny Billquist
2018-04-23 23:57   ` Steve Nickolas
2018-04-24  0:24   ` Ronald Natalie
2018-04-24  0:25   ` Warren Toomey
2018-04-24  0:31     ` Dave Horsfall
2018-04-24  1:02   ` Lyndon Nerenberg
2018-04-24  4:32   ` Grant Taylor
2018-04-24  4:49     ` Bakul Shah
2018-04-24  4:59       ` Warner Losh
2018-04-24  6:22         ` Bakul Shah
2018-04-24 14:57           ` Warner Losh
2018-04-24  6:46   ` Lars Brinkhoff
2018-04-23 22:01 Noel Chiappa
2018-04-23 22:09 ` Warner Losh
2018-04-23 18:41 Noel Chiappa
2018-04-23 19:09 ` Clem Cole
2018-04-23 23:01 ` Dave Horsfall
2018-04-23 23:49   ` Dave Horsfall
2018-04-24  0:26   ` Ronald Natalie
2018-04-22 18:06 Norman Wilson
2018-04-20 16:45 Noel Chiappa
2018-04-20 16:53 ` Charles Anthony
2018-04-20 17:16 ` William Pechter
2018-04-20 23:35   ` Dave Horsfall
2018-04-22 11:48     ` Steve Simon
2018-04-20 15:02 Tim Bradshaw
2018-04-20 15:58 ` Clem Cole
2018-04-20 16:00 ` David Collantes
2018-04-20 16:12   ` Dan Cross
2018-04-20 16:21     ` Clem Cole
2018-04-20 16:33     ` Warner Losh
2018-04-20 19:17       ` Ron Natalie
2018-04-20 20:23         ` Clem Cole
2018-04-20 22:10         ` Dave Horsfall
2018-04-22 17:01     ` Lars Brinkhoff
2018-04-22 17:37       ` Clem Cole
2018-04-22 19:14         ` Bakul Shah
2018-04-22 20:58         ` Mutiny
2018-04-22 22:37           ` Clem cole
2018-04-22 21:51         ` Dave Horsfall
2018-04-25  1:27           ` Dan Stromberg
2018-04-25 12:18             ` Ronald Natalie
2018-04-25 13:39               ` Tim Bradshaw
2018-04-25 14:02                 ` arnold
2018-04-25 14:59                   ` tfb
2018-04-25 14:33               ` Ian Zimmerman
2018-04-25 14:46                 ` Larry McVoy
2018-04-25 15:03                   ` ron minnich
2018-04-25 20:29               ` Paul Winalski
2018-04-25 20:45                 ` Larry McVoy
2018-04-25 21:14                   ` Lawrence Stewart
2018-04-25 21:30                     ` ron minnich
2018-04-25 23:01                 ` Bakul Shah
2018-04-23 16:42         ` Tim Bradshaw
2018-04-23 17:30           ` Ron Natalie
2018-04-23 17:51             ` Clem Cole
2018-04-23 18:30               ` Ron Natalie
2018-04-25 14:02                 ` Tom Ivar Helbekkmo
2018-04-25 14:38                   ` Clem Cole
2018-04-23 20:47               ` Grant Taylor
2018-04-23 21:06                 ` Clem Cole
2018-04-23 21:14                   ` Dan Mick
2018-04-23 21:27                     ` Clem Cole
2018-04-23 22:07                 ` Tim Bradshaw
2018-04-23 22:15                   ` Warner Losh
2018-04-23 23:30                     ` Grant Taylor
2018-04-24  9:37                       ` Michael Kjörling
2018-04-24  9:57                         ` Dave Horsfall
2018-04-24 13:01                           ` Nemo
2018-04-24 13:03                         ` Arthur Krewat
2018-04-23 23:45                   ` Arthur Krewat
2018-04-24  8:05                     ` tfb

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=20180428204008.5D76D18C094@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).