5 Nov
2010
5 Nov
'10
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