Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!spaf
From: spaf@cs.purdue.edu (Gene Spafford)
Newsgroups: comp.os.misc
Subject: Re: a very naive Question???
Message-ID: <5102@medusa.cs.purdue.edu>
Date: 14 Oct 88 05:11:05 GMT
References: <835@amethyst.ma.arizona.edu> <5085@medusa.cs.purdue.edu> <664@cme-durer.ARPA>
Sender: news@cs.purdue.EDU
Reply-To: spaf@cs.purdue.edu (Gene Spafford)
Organization: Department of Computer Science, Purdue University
Lines: 73

In article <664@cme-durer.ARPA> wallace@cme-durer.ARPA (Evan Wallace) writes:
>In article <5085@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.  That is, if the software generates some address
>> like 5 for a storage location, and if the binding to a physical
>> address COULD POSSIBLY be to a hard physical address different
>> from 5, then that implies virtual memory (let's not try to
>> twist this to include fault handling, etc.).
>
>This is mapped memory and not virtual, since the memory accessed is
>indeed existant.

Indeed.  I should have stated that the reference could also map to a fault,
indicating that the location is not currently bound to a physical location.
The fault MAY result in a new binding being created and the reference
retried without any action (or participation) by the faulting task.

>> Virtual memory does not mean that the virtual address range is bigger
>> than the physical address range -- it could be smaller, as in
>
>In "An Introduction to Operating Systems" by Deitel virtual storage
>is defined to be a storage area larger than the primary storage
>area (memory).  This is in direct contradiction with G. Spafford's
>definition, but in complete agreement with common sense.  Also this
>definition is even in my webster's dictionary with a 1966 date of
>origin.?

Neither Webster nor Deitel are necessarily references to quote to me,
especially if you wish to prove a point in operating systems.  Deitel
doesn't address a number of things very well -- that's why we don't
use it here as a text, and Webster never even saw a computer. :-)

I'm not going to waste my time by going through the 20+ OS books I have
on my shelf that I use for references just to tally how many define it
my way.  I waded through those and over 100 articles a few years back
when I did my MS thesis on memory management, and I've been through all
this stuff when I wrote and defended the OS for my PhD, and when I
teach OS, etc.  I *know* what virtual memory is.

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.  If the
program presented an address to the hardware as if it referred to the
physical memory, and if the firmware may possibly bind that to a
different physical address, then it is virtual memory.  The virtual
store  (to use Finkle's terminology) does not have to be bigger than
the physical memory on the machine; it may be smaller.  Virtual memory for
object-oriented systems, for instance, tends to have lots of small
virtual address spaces coresiding in a large physical space.

>> That's how I've taught it in OS courses at both Purdue and
>> Georgia Tech, and that's consistent with many OS texts....
>
>It's unfortunate that this kind of thing gets passed on to students
>who will then continue its propagation.

It's unfortunate that people don't understand what virtual memory is,
and think that the way it is done in Unix is the only correct way.  Too
many people think they understand virtual memory, processes, and OS
design simply because they understand Unix and MS-DOS.  It's
unfortunate that this kind of thing gets passed on to students who will
then continue its propagation.  Happily, I'm not contributing to such
brain rot...and neither are any of my students.


-- 
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu	uucp:	...!{decwrl,gatech,ucbvax}!purdue!spaf