On 2018-02-17 21:56, Larry Baker wrote:
On 17 Feb 2018, at 5:20:13 AM, [email protected]
<mailto:[email protected]> wrote:
Date: Sat, 17 Feb 2018 14:20:00 +0100
From: Johnny Billquist <[email protected] <mailto:[email protected]>>
To:[email protected] <mailto:[email protected]>
Subject: Re: [Simh] pdp11 i/o addressing
Message-ID: <[email protected]
<mailto:[email protected]>>
Content-Type: text/plain; charset=utf-8; format=flowed
On 2018-02-16 22:35, Larry Baker wrote:
Sorry Clem and Bob,
I think you are mixing apples and oranges and adding confusion with your
use of VM to describe two different things.
Yes. We have a conflation of two different things. A rather common
mixup, unfortunately. Even more, though, while your comments below are
accurate, overlays are commonly not done through the MMU at all, so that
is yet another aspect.
My first experience with overlays—the old fashioned kind—was on an IBM
360. I have much experience on RSX. I gave presentations at DECUS
about the easy way to construct overlays.
:-)
Constructing overlays is a big topic. Depending on the program it can be
(maybe) easy, but sometimes it can become rather complex, no matter how
much you try.
(That said, under RSX, there is the option of
having overlay mapping done through the MMU, which is faster, but
potentially waste a lot of memory space.)
RSX offered more than just memory-mapped overlays. (Which, gained us
much speed—not a waste of memory at all.)
Memory mapped overlays potentially wasted lots of space. The "problem"
is that each overlay level must be page aligned, which means 8K aligned.
It also means that you cannot have more than 7 levels, since you only
have 8 pages. Compare to disk based overlays, which can pack the levels
right next to each other, and it should be obvious that you potentially
loose a lot of memory with memory mapped overlays.
RSX Fortran had VIRTUAL
arrays. For us, enough program address space for data was usually the
limitation. I would say that RSX's VIRTUAL arrays come closer to the
true virtual memory concept than memory-mapped overlays.
Good point. Virtual arrays is yet another mechanism, which is really
nice, but with a few limitations.
But virtual arrays really is also a concept which is more akin to demand
paging than virtual memory. Required data is read from disk into memory
when referred to, and written back to disk again when other parts of the
array is needed. But all managed behind the back of the user program.
But also at the user level, just like overlays. The OS is not at all
involved in this at all, and from the OS point of view, it all lives
within the virtual memory space of the process.
I suppose it I am being pedantic, but what you describe is really just
the difference between program or logical address space and physical
address space. The former defined by the architecture, the latter
defined by the implementation. Virtual memory is more than that. See
Denning's http://denninginstitute.com/pjd/PUBS/ENC/vm08.pdf, which
mentions the Manchester Atlas invention of paged virtual memory. Some
of what you described is known as the working set, a concept which
Denning first described.
What you talk about now is demand paging. That really is not virtual
memory itself, but a way to more efficiently implement virtual memory
under some circumstances. But we need to separate the concept from the
implementation.
RSX have virtual memory. But it does not deal with demand paging,
working sets, paged virtual memory, or any such concepts. But it still
have virtual memory. So clearly you cannot claim that virtual memory
requires these concepts.
Demand paging is not virtual memory.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
