3 Nov
2010
3 Nov
'10
12:47 p.m.
On 2010-11-01 00:02, "Chuck Guzis"<cclist at sydex.com> wrote:
Hmm. I don't think swapping is considered to be done in pieces today
either, although swapping is also a term that seems to be defined
differently depending on which OS we're talking about. Unix systems can
both page and swap. Swapping is throwing everything out to disk,
including some kernel structures for the process. Don't happen that
often nowadays... Paging is normally enough.
On 31 Oct 2010 at 11:37, Johnny Billquist wrote:
Ok. So, a program would think it addressed a memory space, which was
it's own, and the addresses it used would in no way related to the
actual physical memory it ended up referring to.
I'd call that virtual memory.
Although, having to map the whole virtual memory as one chunk to
physical memory makes it a little more work, end less flexible than
having pages. And it pretty much prevents you from ever being able to
share memory in a reasonable way between processes.
> The important question here - are the
programs aware of the RA
> register, and can they change it? And can they address the full range
> of memory addresses as perceived by the program.
No they aren't. Their
memory exists from 0 to whatever the field
length is, physically and continously. If they need more, a system
request can expand their field length provided the system has
sufficient physical memory to accommodate them. There is no way
(absent perhaps a system request to get that information) for a
program to know its real physical base address. > Another
word for swapping in and out?
But much older and specific to the architecture and
not done in
pieces as a tranditional VM swap file would be. I'll take the coward's way out and use the
dictionary here:
"1. Existing or resulting in essence or effect though not in actual
fact, form, or name"
So my definiton of "fooling the user into thinking he has more
physical memory than he actually has" is certainly valid.
And the VAX sense is also true, but only if one takes along with it
the ability to over-commit memory space such that the amount of
addressable memory (i.e. the sum of all users' memory) is greater
than the physical memory present.
A single task running on a VAX with at least as much physical memory
as addressing space would not be using the virtual memory facility--
every bit is reflected in the presence of real memory.
But then, we fall on marshy ground again, when we consider the old
"roll/swap" multiuser situation. I can run 8 jobs, each requiring
65K of memory on a system with 128K physical memory, simply by
selecting when I give each a time slice and swapping/rolling them out
as needed. So is that virtual?
Indeed. I remember (not so fondly) running on a PDP-11/70 back in the
80s. The machine was running RSTS/E V7, and the system allows max 63
jobs. We were at times actually 63 users running on that machine, and it
only have 1.5M of memory. It was swapping a lot, and things sometimes
went slow, but it worked perfectly fine. Seeing a machine today with
over 60 users is not common, and I'm not sure it would feel a single bit
more pleasant than the RSTS/E system I used back then...
And I'd still claim that the memory used by each process was definitely
virtual. And I'm willing to continue to fight for that view. Besides,
for the PDP-11, that is what DEC called it. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5 Nov
5 Nov
10:14 a.m.
On 3 Nov 2010 at 20:47, Johnny Billquist wrote:
Ok. So, a program would think it addressed a memory
space, which was
it's own, and the addresses it used would in no way related to the
actual physical memory it ended up referring to. I'd call that virtual
memory. Although, having to map the whole virtual memory as one chunk
to physical memory makes it a little more work, end less flexible than
having pages. And it pretty much prevents you from ever being able to
share memory in a reasonable way between processes.
Well, not really. I refer you to the CDC 7000 SCOPE 2 operating
system. There's a users' manual on bitsavers, but I suspect the
design notebooks have long vanished from the face of the earth--so
there's no documentation on the innards.
At any rate, the CDC 7600 OS people had a peculiar problem. On the
6000 series of machines, PPUs are free-range; they have access to all
of memory and at the time (say, 1968), comprised most of the
operating system--there was almost no CPU code involved. You'd stick
a request into your own location 1 and PP 0 would see it and detail
off the work to the rest of the PPs. Very cool--you never gave up
control of the CPU unless it was to yield to the job scheduler.
But this wasn't possible on the 7600, as each PP was assigned its own
hard-wired slot in CPU memory and was unable to access anything but
that. So the 7600 PPs were detalled off to I/O only. (Now, I'd call
that memory-mapped I/O--you want to to talk to a certain I/O
processor, you communicate with it through a hardware-fixed location
in memory.) Which left the CPU to handle OS tasks such as job
scheduling and file management. A whole new can of worms, as SCM
(the memory that a program could execute from was very fast, but
somewhat limited).
A small permanently-resident "kernel" to handle PP commination and
task swapping was written, but job processing, file management, etc.
was performed for each job with a sort of matryoushka doll setup of
overlapping field lengths. In other words, a user program was
completely enclosed within the record manager which was completely
enclosed within a buffer manager which was completely enclosed within
the job supervisor for that job. So all user memory was shared with
successively higher privilege level tasks, differing only at what
location their respective location 0s were assigned to physical
memory.
The 7600 also had a bulk core "LCM" which couldn't be executed from,
but served for swapping and data storage.
As far as piecemeal swapping, I'll leave that for another time when I
discuss the CDC Zodiac operating system (1970), something for which I
suspect no documentation survives.
--Chuck
4:09 p.m.
Flogging a dead horse perhaps, as I believe the discussion is simply a
matter of differing definitions of the phrase "virtual memory", but
let's try a different approach:
Suppose we have a machine which at the instruction level provides
32-bit addresses, that is, it presents a 32-bit address space (4GB) to
the user. However, there is only 1 MB of physical RAM memory in the
machine.
Without trying to go through the whole history of OS development
(leaving out things such as overlays, shared libs, etc.), and without
accounting for memory required by the kernel/OS for simplicity,
consider several scenarios:
- 1. User addresses map directly to physical addresses.
User address 0 is physical address 0. The user address space is
obviously
limited to 1MB or less of memory and the user will be aware of such
if an
attempt to address beyond that is made.
- 2. We add an MMU to map addresses.
Multiple user address spaces may exist and can be mapped to different
areas in physical memory. User address 0 may or may not ref physical
address 0.
A user is still aware of a limited address space dictated by the 1MB
of
physical memory. The total of the user address spaces cannot exceed
1MB.
- 3. We add swapping-to-disk.
The system as a whole is no longer limited to 1MB of memory, there
may be
multiple user address spaces totalling more than 1MB of memory. Each
user
however, is still limited to a max of 1MB of address space, i.e.
each user
is still aware of the limited physical memory.
- 4. We add address-faulting, demand-paging - whatever one wants to
call it.
The user address space is no longer limited by physical memory. The
user can
hit any address in their 32-bit space and (magically) find a valid
memory
location there. More physical memory can be added (or removed)
'underneath'
the user(s) without their awareness.
By the nomenclature I grew up with or suffer under, the term "virtual
memory" only applies in scenario 4, although "virtual addresses" could
be said to have been introduced in scenario 2.
Or, scenario 4 was my understanding of the *commonly-agreed-upon
application* of the phrase "virtual memory", although I would not argue
that in a very general sense it may be applied to scenario 2 or 3.
3:46 p.m.
On 5 Nov 2010 at 15:09, Brent Hilpert wrote:
By the nomenclature I grew up with or suffer under,
the term "virtual
memory" only applies in scenario 4, although "virtual addresses" could
be said to have been introduced in scenario 2.
My original definition was that "virtual memory" was the ability of a
system (hardware, software, whatever) to fool a program into thinking
that there was more memory present than was physically the case.
Johnny (and please forgive me if I got this wrong) tied it into the
ability to present each user with a address space, such that two
users could use the same address space, but have different data. Key
was the claim that a system with more physical memory than the user
could directly address still qualified as virtual memory.
I don't tie virtual memory into paging or even to multi-tasking or
multi-user, although I'll concede that paging is a way (albeit
rather simple-minded) to implement it. The Burroughs B5000 didn't
employ paging and yet I think few would argue that it did not
implement virtual memory (and quite possibly the earliest commercial
use of it).
--Chuck
6:12 p.m.
On 2010 Nov 5, at 2:46 PM, Chuck Guzis wrote:
On 5 Nov 2010 at 15:09, Brent Hilpert wrote:
By the nomenclature I grew up with or suffer
under, the term "virtual
memory" only applies in scenario 4, although "virtual addresses" could
be said to have been introduced in scenario 2.
My original definition was that "virtual memory" was the ability of a
system (hardware, software, whatever) to fool a program into thinking
that there was more memory present than was physically the case.
Johnny (and please forgive me if I got this wrong) tied it into the
ability to present each user with a address space, such that two
users could use the same address space, but have different data. Key
was the claim that a system with more physical memory than the user
could directly address still qualified as virtual memory. I don't tie virtual memory into paging or even to
multi-tasking or
multi-user,
Agreed, .. I got carried away with building one scenario from the
previous - scenario 4 can stand apart without involving multiple
users/tasks, and so I think meets the def in your first paragraph.
although I'll concede that paging is a way
(albeit
rather simple-minded) to implement it. The Burroughs B5000 didn't
employ paging and yet I think few would argue that it did not
implement virtual memory (and quite possibly the earliest commercial
use of it).
I'm not familiar with the B5000 implementation (did I miss it in the
thread already?), but I did try to avoid restricting the def to that of
paging.
5:39 p.m.
On 5 Nov 2010 at 17:12, Brent Hilpert wrote:
I'm not familiar with the B5000 implementation
(did I miss it in the
thread already?), but I did try to avoid restricting the def to that
of paging.
The B5000, circa 1961 was an amazing bit of equipment. Read about it
here, then compare with later systems.
http://www.ajwm.net/amayer/papers/B5000.html
Makes the PDP-11 seem like a pile of Tinker Toys in comparison.
--Chuck
5:48 p.m.
On 11/5/10 8:39 PM, Chuck Guzis wrote:
Oooohh, tasty! I know what I'll be reading before bed tonight.
I'm not
familiar with the B5000 implementation (did I miss it in the
thread already?), but I did try to avoid restricting the def to that
of paging.
The B5000, circa 1961 was an amazing bit of equipment. Read about it
here, then compare with later systems.
http://www.ajwm.net/amayer/papers/B5000.html Makes the PDP-11 seem like a pile of Tinker Toys in
comparison.
[watches lightning strike Chuck]
--
Dave McGuire
Port Charlotte, FL
9:28 p.m.
On 2010 Nov 5, at 4:39 PM, Chuck Guzis wrote:
On 5 Nov 2010 at 17:12, Brent Hilpert wrote:
Well, you have to love a machine with a "HEYU" instruction (get the
attention of another processor).
I was aware of many aspects of the B5000 series, from AotHoC articles,
but not with the VM implementation technique. The article mentions the
use of a descriptors to indicate memory segment availability, but
doesn't describe much of the VM beyond that. It doesn't make it clear
when VM was actually implemented, I had always been led to believe the
ATLAS was the first VM machine, in the early 60's.
--
Outside the B5000 topic, it is amusing to read the writer's advice in
1982 of "Machines worth keeping an eye on are the iAPX-432 and the IBM
System/38".
I'm not familiar with the B5000
implementation (did I miss it in the
thread already?), but I did try to avoid restricting the def to that
of paging.
The B5000, circa 1961 was an amazing bit of equipment. Read about it
here, then compare with later systems.
http://www.ajwm.net/amayer/papers/B5000.html
Makes the PDP-11 seem like a pile of Tinker Toys in comparison.
9:09 p.m.
On 5 Nov 2010 at 20:28, Brent Hilpert wrote:
I was aware of many aspects of the B5000 series, from
AotHoC articles,
but not with the VM implementation technique. The article mentions the
use of a descriptors to indicate memory segment availability, but
doesn't describe much of the VM beyond that. It doesn't make it clear
when VM was actually implemented, I had always been led to believe the
ATLAS was the first VM machine, in the early 60's.
For a more personal view on the subject of Virtual Memory, have a
read of Richard Waychoff's narrative. He has a completely different
view of what he considers to be virtual memory and ascribes the first
implementation to the B205--a magnetic drum machine:
http://web.me.com/ianjoyner/Files/Waychoff.pdf
Outside the B5000 topic, it is amusing to read the
writer's advice in
1982 of "Machines worth keeping an eye on are the iAPX-432 and the IBM
System/38".
I've never seen a S/38 in person. It would be an interesting system
for a collector to have.
--Chuck
11:22 p.m.
New subject: thin-film and plated-wire memory
Mentioned in the B5000 article was thin-film memory.
Idle curiousity: are there any examples of thin-film memory, or that
other 60's memory alternative - plated-wire memory, still existant?
Perhaps in machines at CHM? How about functioning examples?
6 Nov
6 Nov
6:35 a.m.
New subject: thin-film and plated-wire memory
On Fri, 5 Nov 2010, Brent Hilpert wrote:
Mentioned in the B5000 article was thin-film memory.
Idle curiousity: are there any examples of thin-film memory, or that other
60's memory alternative - plated-wire memory, still existant? Perhaps in
machines at CHM? How about functioning examples?
There have been two examples of plated-wire on Ebay, within the last
two weeks:
220688106698
300483691293
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/
8:30 a.m.
New subject: thin-film and plated-wire memory
Idle curiousity: are there any examples of thin-film
memory, or that other
60's memory alternative - plated-wire memory, still existant? Perhaps in
machines at CHM? How about functioning examples?
There are still a very few Univacs in collections that have plated wire memory.
--
Will
5160
days inactive
5163
days old
11 comments
6 participants
participants (6)
-
bqt＠softjar.se -
cclist＠sydex.com -
hilpert＠cs.ubc.ca -
mcguire＠neurotica.com -
mloewen＠cpumagic.scol.pa.us -
wdonzelli＠gmail.com