30 Apr
2018
30 Apr
'18
9:05 p.m.
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