I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
> From: Johnny Billquist
> This is where I disagree. The problem is that the chunks in the PDP-11
> do not describe things from a zero offset, while a segment do. Only
> chunk 0 is describing addresses from a 0 offset. And exactly which chunk
> is selected is based on the virtual address, and nothing else.
Well, you have something of a point, but... it depends on how you look at it.
If you think of a PDP-11 address as holding two concatenated fields (3 bits of
'segment' and 13 bits of 'offset within segment'), not so much.
IIRC there are other segmented machines that do things this way - I can't
recall the details of any off the top of my head. (Well, there the KA10/KI10,
with their writeable/write-protected 'chunks', but that's a bit of a
degenerate case. I'm sure there is some segmented machine that works that way,
but I can't recall it.)
BTW, this reminds me of another key differentiator between paging and
segments, which is that paging was originally _invisible_ to the user (except
for setting the total size of the process), whereas segmentation is explicitly
visible to the user.
I think there is at least one PDP-11 OS which makes the 'chunks' visible to
the user - MERT (and speaking of which, I need to get back on my project of
trying to track down source/documentation for it).
> Demand paging really is a separate thing from virtual memory. It's a
> very bad thing to try and conflate the two.
Really? I always worked on the basis that the two terms were synonyms - but
I'm very open to the possibility that there is a use to having them have
distinct meanings.
I see a definition of 'virtual memory' below, but what would you use for
'paging'?
Now that I think about it, there are actually _three_ concepts: 'virtual
memory', as you define it; what I will call 'non-residence' - i.e. a process
can run without _all_ of its virtual memory being present in physical memory;
and 'paging' - which I would define as 'use fixed-size blocks'. (The third is
more of an engineering thing, rather than high-level architecture, since it
means you never have to 'shuffle' core, as systems that used variable-sized
things seem to.)
'Non-residence' is actually orthogonal to 'paging'; I can imagine a paging
system which didn't support non-residence, and vice versa (either swapping
the entire virtual address space, or doing it a segment at a time if the
system has segments).
> There is nothing about virtual memory that says that you do not have to
> have all of your virtual memory mapped to physical memory when the
> process is running.
True.
> Virtual memory is just *virtual* memory. It's not "real" or physical in
> the sense that it has a dedicated location in physical memory, which
> would be the same for all processes talking about that memory
> address. Instead, each process has its own memory, which might be mapped
> somewhere in physical memory, but it might also not be.
OK so far.
> each process would have to be aware of all the other processes that use
> memory, and make sure that no two processes try to use the same memory,
> or chaos ensues.
There's also the System 360 approach, where processes share a single address
space (physical memory - no virtual memory on them!), but it uses protection
keys on memory 'chunks' (not sure of the correct IBM term) to ensure that one
process can't tromp on another's memory.
>> a memory management device for the PDP-11 which provided 'real' paging,
>> the KT11-B?
> have never read any technical details. Interesting read.
Yes, we were lucky to be able to retrieve detailed info on it! A PDP-11/20
sold on eBay with a fairly complete set of KT11-B documentation, and allegedly
a "KT11-B" as well, but alas, it turned out to 'only' be an RK11-C. Not that
RK11-C's aren't cool, but on the 'cool scale' they are like 3, whereas a
KT11-B would have been, like, 17! :-) Still, we managed to get the KT11-B
'manual' (such as it is) and prints online.
I'd love to find out equivalent detail for the KT11-A, but I've never seen
anything on it. (And I've appealed before for the KS11, which an early PDP-11
Unix apparently used, but no joy.)
> But how do you then view modern architectures which have different sized
> pages? Are they no longer pages then?
Actually, there is precedent for that. The original Multics hardware, the
GE-645, supported two page sizes. That was dropped in later machines (the
Honeywell 6000's) since it was decided that the extra complexity wasn't worth
it.
I don't have any problem with several different page sizes, _if it makes
engineering sense to support them_. (I assume that the rationale for their
re-introduction is that in the age of 64-bit machines, page tables for very
large 'chunks' can be very large if pages of ~1K or so are used, or something
like.)
It does make real memory allocation (one of the advantages of paging) more
difficult, since there would now be small and large page frames. Although I
suppose it wouldn't be hard to coalesce them, if there are only two sizes, and
one's a small power-of-2 multiple of the other - like 'fragments' in the
Berkeley Fast File System for BSD4.2.
I have a query, though - how does a system with two page sizes know which to
use? On Multics (and probably on the x86), it's a per-segment attribute. But
on a system with a large, flat address space, how does the system know which
parts of it are using small pages, and which large?
Noel
> 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
Depending on the system PS may or may not need to be setuid to work by non-root users.
Ping needs to be setuid because it uses raw sockets which are restricted (much like opening listens on low number ports) in many systems.
> From: William Corcoran
> I think it's a bit more interesting to uncover why rm does not remove
> directories by default thereby obviating the need for rmdir
On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is
setuid-root, since it has to do special magic (writing into directory files,
etc). Given that, it made sense to have 'rm' run with the least amount of
privilege needed to do its job.
Noel
> From: Johnny Billquist
> For 1972 I only found the 11/40 handbook.
I have a spare copy of the '72 /45 handbook; send me your address, and I'll
send it along. (Every PDP-11 fan should have a copy of every edition of every
model's handbooks... :-)
In the meantime, I'm too lazy to scan the whole thing, but here's the first
page of Chapter 6 from the '72:
http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/tmp/PDP11145ProcHbook72pg6-1.j…
> went though the 1972 Maintenance Reference Manual for the 11/45. That
> one also says "page". :-)
There are a few remnant relics of the 'segment' phase, e.g. here:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s
which has this comment:
/ turn on segmentation
Also, if you look at the end, you'll see SSR0, SSR1 etc (as per the '72
handbook), instead of the later SR0, SR1, etc.
Noel
> From: Paul Winalski <paul.winalski(a)gmail.com>
> Regarding the Winchester code name, I've argued about this with Clem
> before. Clem claims that the code name refers to various advances in
> disk technology first released in the 3330's disk packs. Wikipedia and
> my own memory agree with you that Winchester referred to the 3340.
And you believe anything in Wikipedia? If so, I have a bridge to sell you! :-)
But, in this case, it's correct. According to "IBM's 360 and Early 370
Computers" (Pugh, Johnson and Palmer - a very good book, BTW), pg. 507, the
first Winchester was the 3340. The confusion comes from the fact that it had
two spindles, each of 30MB capacity, making it a so-called "30-30" system -
that being the name of Winchester's rifle.
Noel
> From: Johnny Billquist
>> Well, the 1972 edition of the -11/45 processor handbook
^^
> It would be nice if you actually could point out where this is the
> case. I just went through that 1973 PDP-11/45 handbook
^^
Yes, the '73 one (red/purple cover) had switched. It's only the '72 one
(red/white cover) that says 'segments'.
Noel
Blimey, but I nearly missed this one (I was sick in bed).
On this day in 1981, some little company called Xerox PARC introduced
something called a "mouse" (mostly because it has a tail), but I'm
struggling to find more information about it; wasn't there a photo of a
big boxy device?
--
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)
On 2018-04-26 04:00, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote:
> > From: Johnny Billquist
>
> > if you hadn't had the ability for them to be less than 8K, you wouldn't
> > even try that argument.
>
> Well, the 1972 edition of the -11/45 processor handbook called them segments..:-)
I think we had this argument before as well. It would be nice if you
actually could point out where this is the case. I just went through
that 1973 PDP-11/45 handbook, and all it says are "page" everywhere I look.
I also checked the 1972 PDP-11/40 handbook, and except for one mention
of "segment" in the introduction part of the handbook, which is not even
clear if it actually specifically refers to the MMU capabilities, that
handbook also use the word "page" everywhere.
I also checked the PDP-11/20 handbook, but that one does not even cover
any MMU, so no mention of neither "page" nor "segment" can be found.
> I figure some marketing droid found out that 'paging' was the new buzzword, and
> changed the name...:-) :-)
Somehow I doubt it, but looking forward to your references... :-)
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
