🚀 go-pugleaf

In article <8494@duke.duke.UUCP> rjn@duke.UUCP (R. James Nusbaum) writes:
>
>Some very good reasons for large main memories seem to have been ignored
>in the recent discussion.
>[deleted text about paging; large data structures]
>...  While it is true that
>sophisticated software can overcome some of the paging problems, in many
>cases the cost of more memory is less than the total cost of developing
>this software.  In todays world silicon is often cheaper than programmer time.
>
>Jim Nusbaum
>Duke University CS Dept.
>Durham,  NC

All good and well, Jim, but not the topic of discussion.  By `large' we
mean on the order of Gbytes, not Mbytes, at which point various other
factors in the system design can degrade performance substantially.
With a database of hundreds of Gbytes, the paging problems facing a
hypothetical programmer with one or two Gbytes of RAM can actually be much
worse than those facing a programmer with one or two Mbytes worth.
All it takes is a few zillion page faults, and the time lost in page-
search-and-replacement can easily exceed the time gained by a slightly
reduced number of accesses.

babbling again,

-dave
-- 
David Hsu  (301) 454-1433 || -8798 || -8715	"I know no-thing!" -eneevax
Communications & Signal Processing Laboratory	/ EE Systems Staff
Systems Research Center, Bldg 093		/ Engineering Computer Facility
The University of Maryland   -~-   College Park, MD 20742
ARPA: hsu@eneevax.umd.edu    UUCP: [seismo,allegra,rlgvax]!umcp-cs!eneevax!hsu

"Electro-nuclear carburetion seems fine..."

Since most net.arch readers probably don't usually read Business Week
(I was reading it for tax change info :-) I'll point out "Giving Computers
an Elephant's Memory" in BW, Sept 1 86, pg 50.  Mostly about Princeton's M3
(Massive Memory Machine), but also mentions some applications for it and
several companies working on huge memories.

As a mostly-application programmer, I'm deferring comments on the present
pagefaults-and-other-problems discussion to those more knowledgeable.
As a system administrator and sometimes OS tinkerer, I expect a machine
with huge memories will let it be tuned through OS parameters (we're
currently replacing three machines partially because SCO didn't give
us a way to configure XENIX* on them).


* XENIX is a trademark of Microsoft Corporation.  Nobody else wanted it.
-- 
Scot E. Wilcoxon    Minn Ed Comp Corp  {quest,dicome,meccts}!mecc!sewilco
45 03 N  93 08 W (612)481-3507 {{caip!meccts},ihnp4,philabs}!mecc!sewilco
	Laws are society's common sense, recorded for the stupid.
	The alert question everything anyway.

<>
As memory prices drop and other economic things come to pass,
suddenly we have people asking for big fast memory.  Maybe RAM,
maybe SUPER disk, maybe super-cooled core.  Whatever it is going
to be, paging will still go on.  (Atleast thats a best guess, but
I digress)

Decoding an address is a look up.  Simple cascades will not cut it in
the GB or TB range (you laughed at the first guy who said Gig, how
about Tera! :-).  Log(n) is nice, but seconds (plural) is not all that
fun for finding a page, even if you go for 8,16 legged trees (base
8,16).

Perhaps having clusters of pages, grouping allocations.  This would
help for 2000+ user systems (giving everyone their own cluster or even
one per process), but would fail miserably for the 2GB data base.
Each process having a page translation table, and a VM system which
could grok processes or would only look in one place (via another
translation table perhaps).

It keeps coming back to that translation.

Well how about a mix.  A reasonable N MB of virtual memory paged
by whatever scheme you have in hand, and  N TB of physical memory
mapped way out somewhere.  You could have the real near and the
virtual far if you wanted.  Probably easier for faulting and all
that noise.  You still have a VM machine, its just that the VM
is way out there where you may not have to use it.

Yes, this rapes the virtual memory environment.  Segmentation comes
to mind as something to put on top of the two for protection and
address monkeying (every process gets to have its space start at 0
or whatever makes life easy).

Dabble, yes, flames if you must, please be informative with them.

-- 
    Jim Hutchison   UUCP:	{dcdwest,ucbvax}!sdcsvax!hutch
		    ARPA:	hutch@sdcsvax.ucsd.edu
	"Disclaim, disclaim, off to post I go."

>                  Log(n) is nice, but seconds (plural) is not all that
>fun for finding a page, even if you go for 8,16 legged trees (base
>8,16).

As the memories get bigger, all of a sudden random replacement
starts to look not so bad.... :-)

-- 
Jeff Lee
CSNet:	Jeff @ GATech		ARPA:	Jeff%GATech.CSNet @ CSNet-Relay.ARPA
uucp:	...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff

[Time required for virtual memory mapping in huge memory systems]

How about increasing the page size proportionally to the memory
size.  If you got gigabytes to burn what's wrong with a 1 meg page?
-- 
Jerry Natowitz (HASA - A division)
Bell Labs HR 2A-214
201-615-5178 (no CORNET)
ihnp4!houxm!hropus!jin
or ihnp4!opus!jin

Isn't it interesting how the beautiful little red flower in the forest
becomes so ugly when you discover it's a candy wrapper.

If big main memory gets REALLY cheap, maybe we won't need virtual memory any 
more.  Most jobs could just grab a partition of core and live there till they
die.  Another partition could be used to run a virtual machine in for bigger
jobs,  which perhaps could be run as batch jobs in off-hours more profitably...

Peter S. Shenkin	 Columbia Univ. Biology Dept., NY, NY  10027
{philabs,rna}!cubsvax!peters		cubsvax!peters@columbia.ARPA

> If big main memory gets REALLY cheap, maybe we won't need virtual memory any 
> more.  Most jobs could just grab a partition of core and live there till they
> die.  Another partition could be used to run a virtual machine in for bigger
> jobs,  which perhaps could be run as batch jobs in off-hours more profitably...
> 
> Peter S. Shenkin	 Columbia Univ. Biology Dept., NY, NY  10027
> {philabs,rna}!cubsvax!peters		cubsvax!peters@columbia.ARPA

I think my definition of virtual memory might be out of synch with
others.  Cheap large memories mean that we would be able to do away
with demand paging.  We would still need address translation unless
every process was written in position independent code (no address
constants at assembly/compile time etc.)  Does virtual memory imply
demand paging or just address translation?
-- 
Jerry Natowitz (HASA - A division)
Bell Labs HR 2A-214
201-615-5178 (no CORNET)
ihnp4!houxm!hropus!jin
or ihnp4!opus!jin

Isn't it interesting how the beautiful little red flower in the forest
becomes so ugly when you discover it's a candy wrapper.

In article <147@eneevax.UUCP> hsu@eneevax.UUCP (Dave Hsu) writes:
>
>All good and well, Jim, but not the topic of discussion.  By `large' we
>mean on the order of Gbytes, not Mbytes, at which point various other
>factors in the system design can degrade performance substantially.
>With a database of hundreds of Gbytes, the paging problems facing a
>hypothetical programmer with one or two Gbytes of RAM can actually be much
>worse than those facing a programmer with one or two Mbytes worth.
>All it takes is a few zillion page faults, and the time lost in page-
>search-and-replacement can easily exceed the time gained by a slightly
>reduced number of accesses.
>
>babbling again,
>
>-dave
>-- 
>David Hsu  (301) 454-1433 || -8798 || -8715	"I know no-thing!" -eneevax

Your point is also true.  However many Lisp systems are single user systems.
Having even a couple of hundred megawords of memory could totally eliminate
paging, as the entire system could be resident.  Take the Symbolics for
instance.  It has a 200Mb disk used for paging and some middle amount of 
memory (maybe 16Mb).  We have run many complex systems in this 200Mb size.
If we had 200Mb of memory then we would have no need for paging at all!  This
would significantly speed up many applications.

Even 200Mb won't be enough in the near future for some applications, mainly
the VLSI cad systems I've worked on.  And considering the large word size
of some Lisp machine designs (in order to have tag bits) 200Mb can work out
to be only 40Mw.  My whole point, which I admit I didn't get across well, was
that some systems could totally eliminate paging by having huge amounts of
actual memory.  These systems would generally be single user systems, like
Lisp, APL and possibly Prolog machines.

Jim Nusbaum

> If big main memory gets REALLY cheap, maybe we won't need virtual memory any 
> more...

The odds are that the demand for address space will continue to grow faster
than the memory sizes.  In any case, people who argue on this basis miss an
important point:  virtual memory is not a substitute for real memory.  To
quote one of my friends over at HCR:  "real memory for real performance".
The point of virtual memory is not that it's as useful as real memory -- it
is useful in direct proportion to the extent to which it is backed by real
memory -- but that it turns a hard limit into a soft limit.  If you do not
have virtual memory, then a job which doesn't quite fit is unrunnable.  If
you do not have virtual memory, and your main memory is slightly over-
committed, then much more drastic measures like swapping will have to be
used, with much more serious impact on performance.  Virtual memory does
increase the effective size of memory for many applications (big number-
crunching things are often an exception, which is why virtual memory is
not popular in that community; it doesn't do them much good), but it also
makes performance degrade gradually, instead of sharply and disastrously,
when memory is slightly short.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

> ... Does virtual memory imply demand paging or just address translation?

"Virtual memory", strictly speaking, refers to memory that acts like it's
always there but sometimes isn't.  That is, demand paging or some analogous
scheme (paging is not the only memory-management technique possible, and
demand paging is not the only page-fetching policy possible).  Address
translation, by itself, is not virtual memory.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

> ...many Lisp systems are single user systems.
> Having even a couple of hundred megawords of memory could totally eliminate
> paging, as the entire system could be resident...

Well, today it could be.  Two years from now, in the Lisp community, who
knows?  If you drop the ability to do virtual memory, then there is an
awfully sharp cost jump when a program goes from 200MW of memory to 200M+1W.
All of a sudden none of those 200MW machines can run it any more.

There is a lot to be said for memory-rich systems, particularly for Lisp
applications, but discarding virtual memory is throwing out the baby with
the bathwater.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

> /* Written  4:40 pm  Sep  5, 1986 by bzs@bu-cs.BU.EDU in ccvaxa:net.arch */

> Now, ok, you eliminated paging, garbage collection has become a field
> service thing. But, could you do anything useful with all that memory
> and that (relatively) itty-bitty processor? How long would it take you
> to do a MEMQ of a list of a few HUNDRED MILLION lisp objects long?
> etc.
----------
Have you not heard of indexes?  Hash tables?  Arrays?  There are any
number of ways to use memory that don't involve scanning it.  A 2GB
database of bibliographic references (such as Dialog or LEXIS might
have) would run A LOT FASTER if it lived in main memory and wasn't
pounding on the disk interface all the time.  That's not a single-user
example in today's world (it could be eventually, marketed to
libraries and universities), but I have no doubt you can think of
applications that are fully indexed, doing few scans, but using
many, many bytes of data.  The reason you want it in memory is that
you don't know which bytes you'll want or what order you'll want them
in.
----------
> Ok, but still obviously not cost-effective (the magic ingredient that
> gets thrown out whenever this topic starts getting discussed, 1GB of
> memory is going to cost you around $1M
----------
Please allow the user to determine what's cost effective.  If what
you're doing is evaluating huge matrices of seismic data and you
need to do them in N hours because there's a rights auction coming
up, a million may not be an impediment, especially if the machine
can be used as a time-shared engine at times when there isn't a need
for haste.

Betting on those prices holding is about as sensible as betting on
access times holding...

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@gswd-vms

In article <654@hropus.UUCP>, jin@hropus.UUCP (Jerry Natowitz) writes:
> 
> I think my definition of virtual memory might be out of synch with
> others.  Cheap large memories mean that we would be able to do away
> with demand paging.  

Memory may be becoming cheaper, but the addressing range of processors
is becoming bigger.  The IBM XA (I think) is supposed to support 31 
bit addressing, and the Intel 386 is supposed to address 48 bit
addressing!  We still have several generations to go, unless we
settle for very BIG memory boards.

> Jerry Natowitz (HASA - A division)
> Bell Labs HR 2A-214
> 201-615-5178 (no CORNET)
> ihnp4!houxm!hropus!jin
> or ihnp4!opus!jin

-- 
Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey  07102
uucp(for a while) ihnp4!allegra!bellcore!argus!ken
     ***   WARNING:  NOT ken@bellcore.uucp ***
           !psuvax1!cmcl2!ciap!andromeda!argus!ken
bitnet(prefered) ken@orion.bitnet

--- Please resend any mail between 10 Aug and 16 Aug:
--- the mailer broke and we had billions and billions of
--- bits scattered on the floor.

Henry Spencer:
>"Virtual memory", strictly speaking, refers to memory that acts like it's
>always there but sometimes isn't.

I would quibble slightly.  To me, virtual memory refers to a memory space
that is different than the physical memory of the machine.  A PDP-11
has a virtual memory space of 2^16 bytes, or perhaps 2*2^16 bytes.  But
some models of the machine have a physical memory space of nearly 2^22
bytes.

This is not what most people - including me - usually mean when casually
talking about virtual memory.  Then, it does refer to a virtual space that
is larger than the available physical space (available either because
the remainder is allocated to other uses, or not physically present),
and is managed by some technique like demand paging that allows partly-
resident processes to execute.

-- 
Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA
{ucbvax,decvax}!mtxinu!ed   +1 415 644 0146

"A man of quality is not threatened by a woman of equality."

In article <7092@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>> ... Does virtual memory imply demand paging or just address translation?
>
>"Virtual memory", strictly speaking, refers to memory that acts like it's
>always there but sometimes isn't.  That is, demand paging or some analogous
>scheme (paging is not the only memory-management technique possible, and
>demand paging is not the only page-fetching policy possible).  Address
>translation, by itself, is not virtual memory.

Hmmmmm.....  I think I want to take issue with this.  Although what Henry
says is valid, his point is too narrow.  Two immediate counter-examples are
the SDS-940 (later the XDS-940) and the PDP-11, both of which are virtual-
memory machines, and yet essentially just only do address translation.  (I
know, I know, later versions of the PDP-11 can restart instructions; the
point remains.)

Perhaps more to the point would be to say that the memory image seen by the
program is independent of the real memory provided by the machine.  That is,
the operating system can assign arbitrary portions of real memory to the
program and this mapping can change over time.

In this context, some amusing definitions:
   Real:  You've got it, and you know you've got it.
   Transparent:  You've got it, but you don't know you've got it.
   Virtual:  You don't have it, but you don't know it.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA

In article <1162@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes:
>In article <7092@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>>> ... Does virtual memory imply demand paging or just address translation?
>> ... Address translation, by itself, is not virtual memory.
> ... Perhaps more to the point would be to say that the memory image seen by
>     the program is independent of the real memory provided by the machine.

I had always thought that virtual memory meant address translation only, and
that a memory hierarchy (cache, RAM, disk, tape, ...) did not necessarily
exist in a virtual memory system. When I looked it up, however, my textbooks
speak of virtual memory as a way to map backing store into the address space
of the processor:

	"Virtual memory is a technique which allows the execution of
	processes that may not be completely in memory. The main visible
	advantage of this scheme is that user programs can be larger
	than physical memory."
	- Peterson & Silberschatz; _Operating_Systems_Concepts_

	"Virtual memory provides the user with a memory that can be larger
	than physical Mp. The virtual memory system handles overlays in a
	user-transparent manner by deferring the binding between user and
	physical addresses until instruction execution time."
	- Siewiorek, Bell, Newell; _Computer_Structures:_Principles_and_
	Examples_

I got two points from this reading. 1) Virtual memory *technically* implies
only address translation, and 2) The main advantage to using virtual memory
is to extend physical memory via a backing store (disk, drum, ...). Thus, the
concept of virtual memory for all intents and purposes implies swapping memory
to and from a disk, as well as address translation.

Kendall Auel
Tektronix, Inc.

> >"Virtual memory", strictly speaking, refers to memory that acts like it's
> >always there but sometimes isn't.  That is, demand paging or some analogous
> >scheme ... Address translation, by itself, is not virtual memory.
> 
> Hmmmmm.....  I think I want to take issue with this.  Although what Henry
> says is valid, his point is too narrow.  Two immediate counter-examples are
> the SDS-940 (later the XDS-940) and the PDP-11, both of which are virtual-
> memory machines, and yet essentially just only do address translation...

I assure you that the PDP-11 is *not* considered a virtual-memory machine,
not by DEC, not by anyone who knows the machine and knows what the words
mean.  (Well, you can sort of do virtual memory on the 11, but none of the
popular operating systems bother.)  Why do you think the Berkeley Unixes
also go by the name "VMUNIX"?  The "VM" part stands for "virtual memory",
which earlier Unixes -- on the 11, and on the VAX with address translation
but no demand paging -- were not.

> Perhaps more to the point would be to say that the memory image seen by the
> program is independent of the real memory provided by the machine...

This would be a reasonable meaning for the term "virtual memory", but it is
not the standard one.  Check any good operating-systems textbook.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

> >"Virtual memory", strictly speaking, refers to memory that acts like it's
> >always there but sometimes isn't.
> 
> I would quibble slightly.  To me, virtual memory refers to a memory space
> that is different than the physical memory of the machine...

It would be reasonable to use "virtual memory" to denote that concept, but
that is not in fact the concept that it *does* denote.  In the same way,
"RAM" stands for "random-access memory", which one would think should include
things like EPROMs... but in fact "RAM" is now an idiom whose meaning is
not identical to the literal meaning of the words it is derived from.  So
with "virtual memory".

> This is not what most people - including me - usually mean when casually
> talking about virtual memory...

That's because your casual talk uses the phrase in its correct, idiomatic,
meaning, rather than attempting to read it literally and impute to it a
meaning that it never had.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

> I had always thought that virtual memory meant address translation only, and
> that a memory hierarchy (cache, RAM, disk, tape, ...) did not necessarily
> exist in a virtual memory system. When I looked it up, however, my textbooks
> speak of virtual memory as a way to map backing store into the address space
> of the processor...
> 
> I got two points from this reading. 1) Virtual memory *technically* implies
> only address translation, and 2) The main advantage to using virtual memory
> is to extend physical memory via a backing store (disk, drum, ...)...

Can you explain how you arrived at those points from the evidence presented?
Your textbooks clearly state that virtual memory IS the extension of physical
memory via a backing store.  They are correct; the phrase first came into
use to describe exactly that concept.  It's true that its literal meaning is
a bit different, but that's true of any idiomatic term.  The literal meaning
of "computer" is "something which computes, i.e. does arithmetic".  This then
includes a human with a slide rule (in fact, fifty years ago "computer" was
the job title for a desk-calculator operator) and probably does not include
a database machine (which does little or no arithmetic).  But that's not the
meaning normally understood for "computer".
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

In article <7621@tekecs.UUCP> kendalla@blast.UUCP (Kendall Auel) writes:
>In article <1162@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes:
>> ... Perhaps more to the point would be to say that the memory image seen by
>>     the program is independent of the real memory provided by the machine.

>I had always thought that virtual memory meant address translation only, and
>that a memory hierarchy (cache, RAM, disk, tape, ...) did not necessarily
>exist in a virtual memory system.

This is true.  In fact, I have seen a design for an embedded computer with no
backing store that used virtual memory to improve its real memory utilization.
The tasks ran in a largish virtual space and the unallocated memory simply
wasn't mapped.  The memory allocator had some heuristics to minimize the number
of pages occupied and didn't hesitate to leave large sections of the virtual
memory unused and unmapped.  Typically, fragmentation causes you to run out of
space when there is as much as one-third of the memory still available (see
Knuth, Vol. I for details); with this scheme, we could depend upon functioning
with over 90% utilization, and often over 95% -- it was like adding half again
as much memory......

I wish my Amiga used this trick; it's irritating to run out of memory when
the system claims that it still has 220K free.......

>When I looked it up, however, my textbooks
>speak of virtual memory as a way to map backing store into the address space
>of the processor:  [.... quotes deleted .....]
>
>I got two points from this reading. 1) Virtual memory *technically* implies
>only address translation, and 2) The main advantage to using virtual memory
>is to extend physical memory via a backing store (disk, drum, ...). Thus, the
>concept of virtual memory for all intents and purposes implies swapping memory
>to and from a disk, as well as address translation.

An accurate assessment, I think.  Although there are reasons to separate the
two concepts, they work so well together that it is hard to consider them
independantly.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA

<munch>

Re: What is virtual memory?:

One of the big programmer benefits of modern operating systems is that
they give each user his own "virtual machine" to run his programs on,
that is, to some extent, each program thinks it has the machine all to
itself, and doesn't have to worry about what other processes are
doing. Virtual memory is basicaly the "memory" of this virtual
machine. For example, in the PDP-11 example -- each process thought it
was running on a 64K machine. While on this Vax, each program thinks
it is running on a 4 gigabyte machine. While on the 80286, the
machine's virtual memory consists of the fact that it makes it look to
each process as if it can access 64,000 64k segments. Note that paging
is not the only way to do things -- the 80286 has no paging and yet
its memory management scheme certainly qualifies as "virtual memory",
while the PDP-11 also swapped out its 64K segments when something else
needed to be run. But, basically, the point is:

a) Each process is given its own virtual machine, which has a constant
amount of memory, so that

b) programs can be designed for that virtual amount of memory, and do
not have to contain a bunch of special clauses for when the actual
physical amount of memory changes sometime in the future.

The grossest abuse of course is VM, where not only do they make it
look like the process is running on its own processor, but has its own
directly addressible i/o devices also. Talk about taking things to
extremes!
 
  Eric
-- 

      Eric Green {akgua,ut-sally}!usl!elg
        (Snail Mail P.O. Box 92191, Lafayette, LA 70509)

  -- Tengo lo mismo que doy y solo sirve al presente.     

... > Large main memories... Scientific codes can effectively do their
... > own memory management, and do not need to be penalized by VM HW.

J. Giles et al have pretty much persuaded me that virtual memory isn't
always a good thing (it wasn't hard - I was already there).

But, unless you are selling computers strictly to the non-virtual scientific
crowd, a computer manufacturer will probably want to have virtual memory for
his general purpose customers. Your market offering might run like this:
    1.	A general purpose machine/OS with virtual memory
    1'. The ability to turn off virtual memory in machine/OS 1,
	for efficiency of important scientific codes.
    2.  A strictly scientific machine that doesn't have virtual memory
	hardware at all, so scientific codes that don't use virtual
	memory pay no penalty at all.
Assumption: you will probably want these machines to be architecturally
compatible, to save development cost for peripherals and assembly language
code, and so that marketing can tell customers that you have a binary
compatible family of machines... (sigh).

Q1: What features should a machine have so that it can span both virtual and
    non-virtual systems?
Q2: In the non-virtual, scientific, machine 2 do you really want to be
    running a multi-tasking system?
Q3: In a multi-tasking OS, can you mix virtual and non-virtual processes?

If the answer to Q2 is no, you're running a batch system, and you don't
need much special support in the instruction set, at least, to span virtual
and non-virtual systems. Same thing even if you are doing batch style 
multitasking, so long as you don't need to swap processes out and move
them around in core.

What if your customers' answer to Q2 is yes? (Cray seems to think so, with 
their UNIX). If you need to swap processes out and dynamically relocate them
in core, what IS features do you need? 
    I think this question was answered a long time ago - base registers.
Now, my real question is what exactly you need to make base registers useful.
Any takers?

I'm not sure that Q3 is an important question. You're only going to mix
virtual and non-virtual processes if there is a speed advantage to be gained
by turning off translation. Ie. running with the identity map would be
equivalent, except for TLB misses. 

Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms

In article <7110@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:

>I assure you that the PDP-11 is *not* considered a virtual-memory machine,
>not by DEC, not by anyone who knows the machine and knows what the words
>mean.

That's an awfully snippy comment.  Just because the virtual space is smaller
than the physical doesn't mean that it isn't a virtual machine.

>Why do you think the Berkeley Unixes
>also go by the name "VMUNIX"?  The "VM" part stands for "virtual memory",
>which earlier Unixes -- on the 11, and on the VAX with address translation
>but no demand paging -- were not.

"You can call a tail a leg, but that doesn't make it one."

(Actually, that's not quite correct, either.  Indeed, "VMUNIX" is a virtual
memory operating system -- but then, so were the earlier ones.)

I will agree that an extremely strong motivation for virtual memory is so
that you are not required to have all of your program residing in physical
memory.  I will even agree that most virtual memory systems use some form
of paging (or whatnot) for memory management -- but that doesn't mean that
the concepts are the same, or that virtual memory mandates paging.  There
are other, perfectly valid reasons to have virtual memory.

I think the problem here is one of age.  Henry is probably too young to have
heard the terms used correctly and is using the (usually very reasonable)
assumption that if A and B always occur together, then A implies B.  On the
other hand, I worked on the Project Genie time-sharing system (one of the two
original ARPA-funded time-sharing projects; the other was Project Multics),
so I can claim some degree of expertise on the topic.

The fundamental concept of virtual memory is that a large name space (the
virtual memory) can be partially mapped to a smaller name space (the physical
memory) with the remainder of the space unmapped.  Uttering a name that is
not mapped causes some sort of an exception mechanism, but the semantics of
that exception are not part of the virtual memory model.  Admittedly, the
concept is not terribly interesting unless you postulate some exception
semantics, but paging is just one potential set of exception semantics, not
the \only/ one.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA

> "You can call a tail a leg, but that doesn't make it one."
> ...
> I think the problem here is one of age.  Henry is probably too young to have
> heard the terms used correctly and is using the (usually very reasonable)
> assumption that if A and B always occur together, then A implies B...

This is an amusing juxtaposition.  Greg, please see any good computer-science
dictionary and encyclopedia for the *modern* meaning of "virtual memory".
What it was considered to mean twenty years ago is not relevant; that's a
very long time ago in this field.  The meanings of words are defined by how
they are used, not by how they used to be used.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

In article <1181@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes:
>In article <7110@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>
>>I assure you that the PDP-11 is *not* considered a virtual-memory machine,
>>not by DEC, not by anyone who knows the machine and knows what the words
>>mean.
>
>That's an awfully snippy comment.  Just because the virtual space is smaller
>than the physical doesn't mean that it isn't a virtual machine.

I think there is a confusion here on Greg's part between virtual
address space and virtual memory. No one who has studied PDP-11 memory
management will deny that some PDP-11s support virtual addressing.  In
fact, VAX stands for Virtual Address eXtension, implying that the
virtual address concept is not new to DEC's product line.  However,
this is not the same as virtual memory, as Greg seems to think.  The
VAX architecture handbook goes on to say "a virtual memory system is
used to provide a large address space while allowing programs to run
on hardware configurations that actually have smaller memory sizes."

>>Why do you think the Berkeley Unixes
>>also go by the name "VMUNIX"?  The "VM" part stands for "virtual memory",
>>which earlier Unixes -- on the 11, and on the VAX with address translation
>>but no demand paging -- were not.
>
>"You can call a tail a leg, but that doesn't make it one."
>
>(Actually, that's not quite correct, either.  Indeed, "VMUNIX" is a virtual
>memory operating system -- but then, so were the earlier ones.)

I don't see any basis at all for this claim that the earlier forms of
Unix were virtual memory operating systems. Virtual address space,
yes, for memory management is very important to a multi-tasking
operating system. But virtual memory, no.

-- 
 DIP stands for DECnet-DOS Installation Procedure.

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

(The original topic was paging and virtual memory.)

>In article <1181@ncr-sd.UUCP> someone (probably Greg Noel) writes:
>>... Henry is probably too young to have heard the terms used correctly
>>and is using the (usually very reasonable) assumption that if A and B
>>always occur together, then A implies B...

In article <7190@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) replies:
>The meanings of words are defined by how they are used, not by how
>they used to be used.

You are both wrong.

Henry is right in using `virtual memory' as he does; his is the
meaning that is generally accepted in the field.  His usage is
unlikely to cause confusion.  But the meanings of words are not
defined by how they are used.  The meanings of words are defined
by the listener.

Many words are ambiguous.  This is not a failing of the language.
Problems occur only when writers (or speakers) use such words
carelessly.  For example, William Strunk Jr. advises us that the
word `presently'

    Has two meanings: ``in a short while'' and ``currently.''
    Because of this ambiguity it is best restricted to the first
    meaning:  ``He'll be here presently'' (``soon,'' or ``in a
    short time'').

(_The_Elements_of_Style_, William Strunk Jr. and E. B. White, Third
Edition, Macmillan Publishing Co., Inc., New York, p. 57.)  I,
however, disagree:  `It is presently raining' is clear, if not
concise.  In its other incarnation, the word `presently' may be
used as an intensifier.  Neither usage stands alone; the writer
must provide context.

I feel I should also mention that Professor Strunk is, in another
sense, correct.  He also advises us to `omit needless words.'  The
intensifier must be justified.  Consider, for example, this sentence:
`Today was and will be a wonderful day, although it is presently
raining'.  Without the word `presently', it means something entirely
different.

While, as White says in the introduction to Chapter V, `... the
young writer ... will often find himself steering by stars that
are disturbingly in motion', I think that the Computer Science
stars surrounding `virtual memory' have long since settled.  I must
admit that I am even younger a writer than Henry---but I am not,
or not usually, a careless one:  I know my navigation.  Henry is
on course.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

> This is an amusing juxtaposition.  Greg, please see any good computer-science
> dictionary and encyclopedia for the *modern* meaning of "virtual memory".
> 				Henry Spencer @ U of Toronto Zoology

From my dictionary of computer terms:

virtual memory: The mapping of a program address into a physical memory
		address, usually done by hardware.

paging:		The operation of moving pages of information to and from
		secondary storage

Daryl Monge			NET: ihnp4!ihelp!dlm
AT&T				CIS: 72717,65
Bell Labs
Naperville, Ill.

In article <7190@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>...
>What it was considered to mean twenty years ago is not relevant; that's a
>very long time ago in this field.  The meanings of words are defined by how
>they are used, not by how they used to be used.

Quite so.  I remember when 'hacker' was a derogatory term.  I still use
it that way, but no one else seems to.

J. Giles
Los Alamos

In article <842@ihlpm.UUCP>, edsxdev0@ihlpm.UUCP (Bruzzini) writes:
> 
> From my dictionary of computer terms:
> 
> virtual memory: The mapping of a program address into a physical memory
> 		address, usually done by hardware.
> 
> 
> Daryl Monge			NET: ihnp4!ihelp!dlm
> AT&T				CIS: 72717,65
> Bell Labs
> Naperville, Ill.


	I don't know which computer dictionary you are using.  To me,
	virtual memory is a logical memory.  The address space of
	virtaul memory is, usually, >> that of physical one.  The
	mapping is just a mechanism to convert the logical memory
	space to the physical one (in run time).  I believe you
	need a better dictiionary.

>>The meanings of words are defined by how they are used, not by how they
>>used to be used.

>Quite so.  I remember when 'hacker' was a derogatory term.  I still use
>it that way, but no one else seems to.

I remember when 'mainframe' meant 'the computer' (as opposed to the tape
unit or the card reader or the I/O channel -- other big gray boxes in the
computer room). 

Richard Mateosian    ...ucbvax!ucbiris!srm 	     2919 Forest Avenue     
415/540-7745            srm@iris.Berkeley.EDU        Berkeley, CA  94705    

It seems to me that the only thing that this discussion has proved is
that "virtual memory" is an ill-defined term.  Let us accept that fact
and get on to other topics.
-- 

Jeff Gilliam	{ucbvax,pyramid,nsc}!voder!jeff