> https://en.wikipedia.org/wiki/TeX#Pronunciation_and_spelling
Yes, TeX is supposed to be pronounced as Germans do Bach. And
Knuth further recommends that the name be typeset as a logo with
one letter off the base line. Damned if an awful lot of people,
especially LaTeX users, don't follow his advice. I've known
and admired Knuth for over 50 years, but part ways with him
on this. If you use the ready-made LaTeX logo in running text,
so should you also use flourished cursive for Coca-Cola and
Ford; and back in the day, discordantly slanted letters for
Holiday Inn. It's mad and it's a pox on the page.
Doug
> From: Johnny Billquist
> My point being that ... pages are invisible to the process segments are
> very visible. And here we talk from a hardware point of view.
So you're saying 'segmentation means instructions explicitly include segment
numbers, and the address space is a two-dimensional array', or 'segmentation
means pointers explicitly include segment numbers', or something like that?
I seem to recall machines where that wasn't so, but I don't have the time to
look for them. Maybe the IBM System 38? The two 'spaces' in the KA10/KI10,
although a degenerate case (fewer even than the PDP-11) are one example.
I'm more interested in the semantics that are provided, not bits in
instructions.
It's true that with a large address space, one can sort of simulate
segmentation. To me, machines which explicitly have segment numbers in
instructions/pointers are one end of a spectrum of 'segmented machines', but
that's not a strict requirement. I'm more concerned about how they are used,
what the system/user gets.
Similarly for paging - fixed sizes (or a small number of sizes) are part of
the definition, but I'm more interested in how it's used - for demand loading,
and to simplify main memory allocation purposes, etc.
>> the semantics available for - and _visible_ to - the user are
>> constrained by the mechanisms of the underlying hardware.
> That is not the same thing as being visible.
It doesn't meet the definition above ('segment numbers in
instructions/pointers'), no. But I don't accept that definition.
> All of this is so similar to mmap() that we could in fact be having this
> exact discussion based on mmap() instead .. I don't see you claiming
> that every machine use a segmented model
mmap() (and similar file->address space mapping mechanisms, which a bunch of
OS's have supported - TENEX/TOP-20, ITS, etc) are interesting, but to me,
orthagonal - although it clearly needs support from memory management hardware.
And one can add 'sharing memory between two processes' here, too; very similar
_mechanisms_ to mmap(), but different goals. (Although I suppose two processes
could map the same area of a file, and that would give them IPC mapping.)
Noel
> From: Johnny Billquist
>> "A logical segment is a piece of contiguous memory, 32 to 32K 16-bit
>> words long [which can grow in increments of 32 words]"
> But then it is not actually giving programs direct access and
> manipulation of the hardware. It is a software construct and service
> offered by the OS, and the OS might fiddly around with various hardware
> to give this service.
I don't understand how this is significant: most time-sharing OS's don't give
the users access to the memory management control hardware?
> So the hardware is totally invisible after all.
Not quite - the semantics available for - and _visible_ to - the user are
constrained by the mechanisms of the underlying hardware.
Consider a machine with a KT11-B - it could not provide support for very small
segments, or be able to adjust the segment size with such small quanta. On the
other side, the KT11-B could support starting a 'software segment' at any
512-byte boundary in the virtual address space, unlike the KT11-C which only
supports 8KB boundaries.
Noel
> From: Johnny Billquist
>> in MERT 'segments' (called that) were a basic system primitive, which
>> users had access to.
> the OS gives you some construct which can easily be mapped on to the
> hardware.
Right. "A logical segment is a piece of contiguous memory, 32 to 32K 16-bit
words long ... Associated with each segment are an internal segment
identifiern and an optional global name." So it's clear how that maps onto the
PDP-11 memory management hardware - and a MERT 'segment' might use more than
one 'chunk'.
>> I understand your definitions, and like breaking things up into
>> 'virtual addressing' (which I prefer as the term, see below),
>> 'non-residence' or 'demand loaded', and 'paging' (breaking into
>> smallish, equal-sized chunks), but the problem with using "virtual
>> memory" as a term for the first is that to most people, that term
>> already has a meaning - the combination of all three.
Actually, after some research, it turns out to be only the first two. But I
digress...
> It's actually not my definition. Demand paging is a term that have been
> used for this for the last 40 years, and is not something there is much
> contention about.
I wasn't talking about "demand paging", but rather your use of the term
"virtual memory":
>>> Virtual memory is just *virtual* memory. It's not "real" or physical
>>> in the sense that it has a dedicated location in physical memory
>>> ... Instead, each process has its own memory, which might be mapped
>>> somewhere in physical memory, but it might also not be. And one
>>> processes address 0 is not the same as another processes address
>>> 0. They both have the illusion that they have the full memory address
>>> range to them selves, unaware of the fact that there are many
>>> processes who also have that same illusion.
I _like_ having an explicit term for the _concept_ you're describing there; I
just had a problem with the use of the _term_ "virtual memory" for it - since
that term already has a different meaning to many people.
Try Googling "virtual memory" and you turn up things like this: "compensate
for physical memory shortages by temporarily transferring data from RAM to
disk". Which is why I proposed calling it "virtual addressing" instead.
> I must admit that I'm rather surprised if the term really is unknown to
> you.
No, of course I am familiar with "demand paging".
Anyway, this conversation has been very helpful in clarifying my thinking
about virtual memory/paging. I have updated the CHWiki article based on it:
http://gunkies.org/wiki/Virtual_memory
including the breakdown into three separate (but related) concepts: i) virtual
addressing, ii) demand loading, and iii) paging. I'd be interested in any
comments people have.
> Which also begs the question - was there also a RK11-A?
One assumes there much have been RK11-A's and -B's, otherwise they wouldn't
have gotten to RK11-C... :-)
I have no idea if both existed in physical form - one might have been just a
design exercise). However, the photo of the non-RK11-C indicator panel
confirms that at least one of them was actually implemented.
> And the "chunks" on a PDP-11, running Unix, RSX or RSTS/E, or something
> similar is also totally invisible.
Right, but not under MERT - although there clearly a single 'software' segment
might use more than one set of physical 'chunks'.
Actuallly, Unix is _somewhat_ similar, in that processes always have separate
stack and text/data 'areas' (they don't call them 'segments', as far as I
could see) - and separate text and data 'areas' too, when pure code is in
use; and any area might use more than one 'chunk'.
The difference is that Unix doesn't support 'segments' as an OS primitive, the
way MERT does.
Noel
> That would be a pretty ugly way to look at the world.
'Beauty is in the eye of the beholder', and all that! :-)
> Not to mention that one segment silently slides over into the next one
> if it's more than 8K.
Again, precedent; IIRC, on the GE-645 Multics, segments were limited to 2^N-1 pages,
precisely because otherwise incrementing an inter-segment pointer could march off
the end of one, and into the next! (The -645 was implemented as a 'bag on the side'
of the non-segmented -635, so things like this were somewhat inevitable.)
> wouldn't you say that the "chunks" on a PDP-11 are invisible to the
> user? Unless you are the kernel of course. Or run without protection.
No, in MERT 'segments' (called that) were a basic system primitive, which
users had access to. (Very cool system! I really need to get moving on trying
to recover that...)
> *Demand* paging is definitely a separate concept from virtual memory.
Hmmm. I understand your definitions, and like breaking things up into 'virtual
addressing' (which I prefer as the term, see below), 'non-residence' or
'demand loaded', and 'paging' (breaking into smallish, equal-sized chunks),
but the problem with using "virtual memory" as a term for the first is that to
most people, that term already has a meaning - the combination of all three.
(I have painful memories of this sort of thing - the term 'locator' was
invented after we gave up trying to convince people one could have a network
architecture in which not all packets contained addresses. That caused a major
'does not compute' fault in most people's brains! And 'locator' has since been
perverted from its original definition. But I digress.)
> There is no real connection between virtual memory and memory
> protection. One can exist with or without the other.
Virtual addressing and memory protection; yes, no connection. (Although the
former will often give you the latter - if process A can't see, or name,
process B's memory, it can't damage it.)
> Might have been just some internal early attempt that never got out of DEC?
Could be; something similar seems to have happened to the 'RK11-B':
http://gunkies.org/wiki/RK11_disk_controller
>> I don't have any problem with several different page sizes, _if it
>> engineering sense to support them_.
> So, would you then say that such machines do not have pages, but have
> segments?
> Or where do you draw the line? Is it some function of how many different
> sized pages there can be before you would call it segments? ;-)
No, the number doesn't make a difference (to me). I'm trying to work out what
the key difference is; in part, it's that segments are first-class objects
which are visible to the user; paging is almost always hidden under the
sheets.
But not always; some OS's allow processes to share pages, or to map file pages
into address spaces, etc. Which does make it complex to separate the two..
Noel
> 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
