Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!urth!rfm
From: rfm%urth@Sun.COM (Rich McAllister)
Newsgroups: comp.os.misc
Subject: Defining virtual memory (was: a very naive Question???)
Summary: 360's didn't have virtual memory
Message-ID: <73039@sun.uucp>
Date: 14 Oct 88 18:18:49 GMT
References: <835@amethyst.ma.arizona.edu> <5085@medusa.cs.purdue.edu> <664@cme-durer.ARPA> <5102@medusa.cs.purdue.edu>
Sender: news@sun.uucp
Reply-To: rfm@sun.UUCP (Rich McAllister)
Organization: Sun Microsystems, Mountain View
Lines: 30

In article <5102@medusa.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) 
writes:
>The definition I use in teaching OS courses is the following:
> 
>If the address presented to the system may be bound to a physical
>address different from that seen by the program, you have
>virtual memory.

Later, in article <5085@medusa.cs.purdue.edu>, he remarks: 

>The definition I gave happens to cover the memory scheme on systems
>your definition doesn't -- like TSO on a 360, old NOS on a  CDC 6600,
>and various DEC OS systems on their earlier PDP machines.

I think this demonstrates the best reason not to use this definition of
"virtual memory" -- it loses the history of the term.  The term was
popularized by IBM when it introduced the 370/158 and /168 and OS/VS -- the
main distinction drawn between the new OS and the old was: the new one has
virtual memory, the old one doesn't.

Also, the common definition of virtual is "existing in appearance but not 
in fact," which doesn't seem to apply to a simple remapping of addresses
of memory which exists "in fact".

A proper definition of "virtual memory" should capture the idea that the
data stored in a part of the address space may be held somewhere other
than in main storage when not being referenced.  


Rich McAllister (rfm@sun.com)