From: charliec@Everest.Tandem.COM (Charlie Comstock)
Subject: Re: need advice on ultimate Amiga system
Organization: Tandem Computers Inc., Cupertino CA
Date: Mon, 6 Apr 1992 22:58:16 GMT

In article <sapjd0p@lynx.unm.edu>, kholland@hydra.unm.edu (Kiernan Holland) writes:
>In article <bobl.32jx@bobsbox.rent.com> bobl@bobsbox.rent.com (Bob Lindabury, SysAdmin) writes:
>>In article <-zmjawk@lynx.unm.edu> kholland@hydra.unm.edu (Kiernan Holland) writes:
>>>In article <56902@cup.portal.com> blackbelt@cup.portal.com (Ben - Williams) writes:
>>>>Michael COmet,
>>>>
>>Erg.  Yet more idiotic drivel from Kiernan who knows *nothing* of what
>>he's saying.  Jezz I wish my news reader had a kill file!
>>
>>-- Bob
>
>Ok, what do you think I was talking about???
>This is what i was talking about:
>
>1. 2D morphing according to the jackson video described in CGW 
>   (working from my bio-storage here) was not automatic. 
>   You have to control the paths of the morphing. 
>
>2. Amiga devlopers do not currently support pseudo VM
>   probably either because:
>	  a. theynever thought of it. 
>	  b. they don't know what it is. 
>	  c. they are tooo lazy.
>	  d. they don't think they need pseudo VM becuase 
>		 it is tooo slow. 
>	  e. the amiga users don't know what it is?
>	  f. they don't think the amiga users can tell the difference
>		 then it shouldn't be implemented. 
>	  g. they assume CBM will put VM in amigados. 
>	  h. who knows, why.
>
>It really doesn't look like the people I have talked to 
>about VM are not very realitic about its implementation 
>into software, using excuses such as:
>
>Awww, I got 32 megs of ram and I never have problems 
>running programs on my amiga. 
>
>Oh, CBM will support therefore I shouldn't have to screw with 
>my program to support VM. 
>
>It is toooooo slow, I want a fast program. 
>
>---------------------------------------------------
>I really don't think half of you guys know what 
>VM is. If you do, you would understand what 
>use it would be to amiga users with big hard drives and 
>small pocket-books. I swear, you must have no conception 
>of how horrible it is to run out of memory on a 
>1.3 meg system when you are saving up for something 
>that you really want like a PC >:-P. 
>
>Go off and ignore me, the others will see the light.

Sorry Kiernan, I fail to concur with your argument that VM should be
implemented by all developers.

I must fall into the half that do know what VM is.  Since you apparently
do not I'll try and explain it.  VM stands for virtual memory.  It is a
way of mapping a large virtual memory space onto a smaller (usually)
amount of physical memory.  When not enough physical memory is available
to hold all of the virtual (or logical) memory some portion of virtual
memory is kept in a disk file (actually all of virtual memory is usually
kept in a disk file).  The beauty of this system is that computers with
small amounts of physical memory can run programs that require large
amounts of ram.  Only the portions of memory actually being worked on
(recently) are kept in physical memory.  Most versions of Unix, other
mainframe operating systems, minicomputer operatings systems and (I think)
OS/2 2.0 have virtual memory built in.

The implementation of virtual memory can be done in several ways.  Usually
memory (virtual and physical) is divided into 'pages'.  A page can be either
fixed or variable size.  Pages can be absent (only in the disk file but not
in memory), present (in memory), or dirty (in memory but changed relative
to the disk file.  A program makes all of its accesses in virtual memory
space.  When a memory access falls within a page that is not present the
memory manager scans the list of pages in physical memory looking for one
that isn't in use.  If an unused page can't be found it looks for a used
page that hasn't been accessed for a while (on the theory that it won't
quickly be used again.  A preference is given to pages which are not dirty
since a dirty page must be written out to the virtual memory swap file
before it can be reused.  Once a physical page has been glommed onto, the
contents of the virtual page in the swap file are read into the page in
memory.

Because the virtual pages can be placed in any physical page in memory
some form of address translation is required.  Two ways come to mind.

The hardway is to manually partition your program's code or data (code is
optional since its usually data that takes up the 30mb of space) into
pages.  Each page then gets its base address saved.  Anytime your program
needs to use data however it must now go through an extra level of 
indirection to figure out where the data is.  This adds a lot of extra
clocks to its execution time.

The easy way is to use address translation built into the hardware of 
many modern processors such as 68030, 68040, 80386, 80486, R3000, etc...
In this case the processor's address translation checks to see if your
reads or writes are going to an absent page.  If not the addresses are
adjusted and the proper physical address is placed on the memory bus (or
whatever means are implemented in a given design to access ram).  If the
page is absent then a page-fault interrupt occurs.  The memory manager
services this interrupt by looking for a suitable page of physical
memory, (preference for unused pages, pages which are not dirty, and as
a last resort dirty pages).  If the page is dirty its contents get written
out to the swap file.  The page in the swap file which was desired in the
first place is now loaded into our newly acquired physical page and now
we're ready to resume execution from where we took the page-fault interrupt.
Except for one little detail....  The instruction that the page-fault needs
to be restarted.  In the Motorolla 680x0 family 68010 and up chips have
this instruction restart capability.  The 68000 doesn't.  This makes a
68000 system pretty unsuitable for this method of performing VM.
(In the real world things get a little more complicated as the address
translation lookup table in hw is generally too small for all the entries
needed so a cache is provided to hold the most recently used ones).

What are the tradeoffs?  The software only method can be made to run on
any machine (at the expense of extra programming effort and a lot of extra
execution time).  The hardware method doesn't require any special
programming on the part of the applications programmer and doesn't use
more clocks (unless the hardware is slow).  Both methods will get really
slow if there is memory requests are scattered randomly throughout virtual
memory (such as might happen when ray tracing a scene with 100,000+ polygons
in it)since this will tend to cause a lot of page faults (and disk accesses).

Based on this it would seem as though hw based VM is the way to go!  Many
Amigas already have processors capable of doing this.  Why not have every
application programmer come up with their own scheme of doing it?  _NOT_!!!!
C= specifically states that the address translation hardware is reserved
for future use!  This means that anyone foolish enought to build their own
VM system would be guaranteed of having the program break when some new
version of the os comes along.  These programs also wouldn't work with
some debuggeres and Enforcer, with each other, or on systems with out
memory manager hardware (68010 or 68020 with mmu chip) or on systems without
instruction restart (68000).

Apparently Kiernan, you would like all developers to write code that at some
point in the future won't work!  If we are ever going to have VM on the
Amiga I'm afraid that we're stuck waiting for some standard for it to emerge,
either from C= or since they won't do it, from somebody C= aproved (oops,
C= has already done it!  Something about Amiga Unix?)

What we need now is for programs that use LARGE chunks of ram (ADPro,
ImageMaster, etc..) to use standard disk files to store the portions of
pictures (or whatever) that are not being manipulated at this micro-second.
This however, is not 'virtual memory'.

Charlie Comstock 
Newsgroups: comp.sys.amiga.graphics,comp.sys.amiga.marketplace