Re: Virtual Memory on a //GS???????????????????

[cxcheng@dvlsun1.oracle.com (Calvin Cheng)]

In article <2i6hbv$t07@schema.fiu.edu>, richard@fiu.edu (Albert
Chin-A-Young) writes:
> Path:
oracle!gatekeeper.us.oracle.com!sgiblab!sgigate.sgi.com!olivea!spool.mu.
edu!howland.reston.ans.net!darwin.sura.net!usenet.fiu.edu!richard
> From: richard@fiu.edu (Albert Chin-A-Young)
> Newsgroups: comp.sys.apple2
> Subject: Re: Virtual Memory on a //GS???????????????????
> Date: 26 Jan 1994 19:47:11 GMT
> Organization: Florida International University, Miami, Florida
> Lines: 17
> Message-ID: <2i6hbv$t07@schema.fiu.edu>
> References: <9401261321.AA18392@clarknet.clark.net>
> NNTP-Posting-Host: solix-gw.fiu.edu
> 
> In article <9401261321.AA18392@clarknet.clark.net>,
>  <ncp@gnh-starport.UUCP> wrote:
> }The way other OSs do virtual memory would be to slow for the GS to do, and I
> }know that the Mac relies on extra hardware to do it's virtual memory.  It
> }would be nice, and maybe someone would make it available on the application
> }level, but don't expect to see this on the GS, ever.  If the GS could do it,
> }thoguh, you could conceivably see an extra 14 megs max. off of your hard
> }drive.  I would rather see someone try to expand the eight meg limit to 16
> }thorugh hardware somehow (fat chance, I know). :)
> 
> Well, with Ken Poppleton's DSP and a slight modification to the interface
> board, we can have virtual memory (which implies we can get memory
> protection too).
> 
> }NCP                        ncp@gnh-starport.clark.net
> 
> albert

For virtual memory, you need restartable instructions.  For example, if you get
a memory fault while accessing a virtual location, you must be able to restart
the instruction with no sideeffects after the virtual location has been mapped
to a physical location during the memory fault trap.  That's also one big
argument for RISC: the 68030 pushes some 300 bytes of internal state info onto
stack upon a memory fault I think.

My OS class professor told us that the original 68000-based Sun 1/2
workstations
didn't get any virtual memory support from the hardware.  They simulated
restartable instructions by having 2 68000.  When the first gets interrupted
because of a memory error, the second one suspends the first one in its
existing
state, handles read/writing to storage, and puts the first one back on exactly
where it left off.  Neat hack.  This could be what the DSP can do.

Virtual memory is also almost always associated with page-based address
translation.  You can conceivably implement this in software, but think of how
slow it can get without hardware support in the form of hardware lookup tables/
caches.  Demand page-based systems also give you the nicety of memory
protection
as well as interesting hacks like sharing one common chunk of memory between
multiple processes.

The system of dynamic loading and purging of resources on the Mac and IIGS
is a better system of memory management in the absence of appropriate
hardware resources though.  And the Mac does a really horrible job at virtual
memory.  This having much to do with the design of the OS (single address
space, multiple processes; a disk caching system that doesn't work well with
virtual memory; memory resource allocation scheme that doesn't go well with
VM; horrible, even laughable context switching time etc).

+--------------------+----------------------------+-----DISCLAIMER---------+
| Calvin Cheng       | E-mail: cxcheng@oracle.com | "All great works are   |
| Sun Products Group | V-mail: (415) 506-6022     | done in defiance of    |
| Oracle Corporation | Fax:    (415) 506-7200     | management"- B Woodward|
+--------------------+----------------------------+------------------------+