[Simh] Memories are made of this ...

[dave porter]

And an even stronger curmudgeon warning here then.

According to the terminology I (another curmudgeon) grew
up on and still use, you're conflating virtual addressing and
virtual memory.

Virtual addressing is where each job/task/process/etc gets
its own address space. This can be implemented by something
as simple as datum and limit registers. The benefits include
mutual protection and the ability to link independently of
the eventual load address.

(i.e., the addresses are virtualized, the addressed storage
is not)

Virtual memory is where not all of a virtual address space
is necessarily backed by storage directly addressable by
the processor, at any given point in time. The benefits
include more efficient use of physical memory and the
ability (given enough address bits) to have an address
space exceeding physical limits, without burdening the
app programmer with managing the migration.

(i.e., the addressed storage is itself virtualized)

[Larry Baker]

Date: Sat, 17 Feb 2018 14:20:00 +0100
Subject: Re: [Simh] pdp11 i/o addressing
Content-Type: text/plain; charset=utf-8; format=flowed

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.

(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.) 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.

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.

Johnny

Tim left unnamed a machine that considered everything memory, even I/O. I bet that was Multics. I admire some of Multics' ambitions, but practicalities doomed the effort. Kind of like micro kernels, ala Mach and OSF/1. A good idea for designing a system, but not necessarily for implementing one.

Larry Baker
US Geological Survey
650-329-5608
***@usgs.gov

[Johnny Billquist]

Date: Sat, 17 Feb 2018 14:20:00 +0100
Subject: Re: [Simh] pdp11 i/o addressing
Content-Type: text/plain; charset=utf-8; format=flowed

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]

Post by dave porter

And an even stronger curmudgeon warning here then.

According to the terminology I (another curmudgeon) grew
up on and still use, you're conflating virtual addressing and
virtual memory.

Uh... A virtual address give the address to a virtual memory cell.

Post by dave porter
Virtual addressing is where each job/task/process/etc gets
its own address space. This can be implemented by something
as simple as datum and limit registers.  The benefits include
mutual protection and the ability to link independently of
the eventual load address.
(i.e., the addresses are virtualized, the addressed storage
 is not)

Yes. But that also means that you need have some backing store for the
data stored at those virtual addresses, or else it don't mean anything.
And that backing store is memory, which then is virtual. This virtual
memory can then, in turn, either be backed by physical memory, or by
some secondary storage. Don't matter. It is backed by some storage, or
else it won't exist.

Post by dave porter
Virtual memory is where not all of a virtual address space
is necessarily backed by storage directly addressable by
the processor, at any given point in time. The benefits
include more efficient use of physical memory and the
ability (given enough address bits) to have an address
space exceeding physical limits, without burdening the
app programmer with managing the migration.
(i.e., the addressed storage is itself virtualized)

I never said it all had to be backed by storage directly addressable by
the processed at any given point in time. Virtual memory just means that
it has the appearance of being your own, private memory. It might, or
might not be backed by physical memory at any specific point in time.
I also said that on some machines, where the virtual memory space is
rather small, and physical memory is large, it is common that the system
either have all or none of the virtual memory mapped to physical memory
at the same time, but that is just one implementation, and not a
requirement.

However, if you want to have virtual memory where not all of memory is
backed by physical memory at the same time, then you normally require an
additional mechanism, called demand paging. Demand paging is not virtual
memory per se, but a mechanism for handling virtual memory where you
only have parts of the virtual memory mapping into physical memory.
But don't make the mistake of thinking that demand paging is virtual
memory. They are two different things, and you have can virtual memory
without demand paging.

Johnny