Virtual memory

Johnny Billquist bqt at
Sun Oct 31 05:37:47 CDT 2010

On 2010-10-30 23:18, "Chuck Guzis"<cclist at> wrote:

> On 29 Oct 2010 at 21:14, Johnny Billquist wrote:
>> >  If your program vrites data to address 0, and reads it back, and get
>> >  the same data back, and another program on the same machine, at
>> >  roughly the same time, write to address 0, and reads the same data
>> >  back, and that data is different than the first programs data, then
>> >  I'd say you have virtual memory.
> So, your definition ties virtual memory into multi-user access?
> That's not the way I learned it.

No no no. You miss my point. It don't directory tie in to multiuser 
access. It's about presenting to you a memory which in reality does not 
exist as you perceive it. As a follow on benefit of this is the fact 
that you can have multiple instances at the same time. But that is not 
the definition.
The definition is that you appear to have a linear space of memory that 
maps the whole virtual address range, and that this memory is yours 
alone. It is your own private memory. Just as a virtual machine is your 
own private machine. No matter the fact that in reality, this is not the 
case, and your memory (or machine) is just something running under the 
control of an underlying operating system, which gives you this service.

> Consider (again folks, I'm sorry for the reference) the CDC 6600
> (circa 1964).  Every user is given a relocation address (called RA)
> and field length (FL) as a way of partitioning main memory.  Each
> user's memory addressing space is kept isolated from every other's
> and this fits your definiton because one user's location X was
> different from every other user's location X and there was no way for
> a user to tell what his RA was; i.e. each user was safely "boxed in".

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.

> That's not virtual memory by any stretch of the definition.  Over-
> committing memory meant writing/reading the entire FL of a user to
> disk ("rollout" and "rollin").

Another word for swapping in and out?

Anyway, I'm not sure if this would qualify as virtual memory or not 
without knowing a few more details. But it might very well be virtual 
memory, as far as I can tell.

> Now consider the STAR-100 (I think it would qualify as the first
> virtual memory machine of CDC), circa 1969.

Defined by whom? CDC? Or you guys? ;-)

>  Every user got an
> addressing space of 48 bits, but the machine itself had only
> 512Kwords (64 bit) of physical storage.  For production use, most of
> the time the system was run in single-user mode (kept thrashing down
> with large data sets).  That fits my definition of VM because the
> user was fooled into thinking that there was more physical memory
> than there really was.

You know, my definition and yours don't necessarily disagree on all 
points. Both would define the VAX as having virtual memory (well, except 
for the fact that yours might not, if you have a VAX with enough 
physical memory). We just disagree about what when there is more 
physical memory than you have virtual memory space. For you, that means 
it can't be virtual memory. but for me it can.

For me, what is relevant is whether the program is presented with his 
own private memory space, which contains all addresses he can address, 
and where all those addresses are valid and working. A memory space 
which he don't have to share with anyone else. That's what virtual 
memory is, as opposed to physical memory, which you can point at, and 
which all running code on a computer needs to live on. And that means 
that the OS is always there. And possibly other processes as well. Using 
the same addresses you are. If that means that you cannot have your own 
memory for a specific address, then it's not virtual memory. But then 
you probably aren't talking about virtual memory either, but physical 

> Aside from expanding program storage, the large addressing space was
> used to map file space (another type of "memory-mapped I/O"), so file
> access was actually performed through the paging hardware/software.
> That was kind of cool, as the STAR was a memory-to-memory vector
> machine, so you could use vector instructions on entire files, rather
> than have to issue reads and writes for pieces of a file.
> So I think we differ considerably in our definitions.

On some parts, yes. So, do the VAX not have virtual memory? After all, I 
can fill a VAX with more physical memory than you can address virtually.


Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

More information about the cctalk mailing list