Path: utzoo!attcan!uunet!maverick.ksu.ksu.edu!hoss!fergvax!252u3130
From: 252u3130@fergvax.unl.edu (Phil Dietz)
Newsgroups: comp.sys.amiga.tech
Subject: Virtual Memory
Message-ID: <1990Oct09.173145.3883@hoss.unl.edu>
Date: 9 Oct 90 17:31:45 GMT
References: <1990Oct7.032409.22928@zorch.SF-Bay.ORG> <lron.1044713@easy.HIAM> <1990Oct9.061755.15112@zorch.SF-Bay.ORG> <32894@nigel.ee.udel.edu>
Sender: news@hoss.unl.edu (Network News Administer)
Organization: Comp Sci and Engr, Univ. of Nebr.
Lines: 25

It's a pretty interesting idea though.  The only way I could see this
being done would be with a MMU.
 
Theoretically it would be easy to emulate VM.  Simply create a new
Exec.library.  All the subroutines that acces or create memory would
have added commands and flags, such as a process id for each program and
task.  This task id would be held in a reserved area of memory in a 
memory map or hash section.  Each task is alloted a certain amount of
memory in each PAGE of memory.  When the page is full, the underlying VM
handler would swap pages, the program memory map areas would be found,
and the memory program would run some more.
 
The only problem is telling ALL software that all the memory is for
private VM storage and that they should create memory VIA the nice exec
methods.  Other than this problem, vitual memory should be able to work
with all programs.
 
<will discuss more later>
Phil Dietz



<<<=================--------- Cheap Ad ---------===================<<<
Phil Dietz                       SWL Lincoln    550 MEGS! 2 lines
252u3130@fergvax.unl.edu         (402)421-1963  IBM, GIFS, MAC, AMIGA