🚀 go-pugleaf

In article <EACHUS.90Oct2113309@aries.linus.mitre.org> eachus@linus.mitre.org (Robert I. Eachus) writes:

>     A couple of comments on this issue.  First don't use T: for
>paging.  This has come to be the place to put small temporary files,
>and most users have it assigned to RAM: or some other ram disk. The
>best idea would be to use a new name such as SWAP:

	Sorry, too late.  WordPerfect already uses T: for its storage.

>     Second, I like the library idea, and doing it right should be
>easy and highly portable.  Create a swap.device -- actually two, one
>for machines with MMU's and one for machines without.  Programs would
>be would be guaranteed that the most recently seeked to page was
>valid.  The swap device would have to write all pages opened
>read/write when it was necessary to flush them on the non-MMU version,
>but could check the hardware flags on the MMU version.

	Software VM would require a great deal of locking/unlocking code
to make certain that the data you are accessing is in memory when its needed
and can be purged when its not.  If the same program were to run on a
machine with an MMU, you would still be executing all of that code, so the
MMU would buy you nothing.  The overhead involved in locking and unlocking
chunks of data would greatly slow execution especially if it involved library
or function calls.  Macros would be best.  Pointers would not be valid
unless VM had its own address space.  

	You would receive about the same benefit as using fread()/fwrite()/
lseek() but your buffers would eventually take up all free RAM.  The only 
advantage would be the ability to control the size of the resulting file.
This is not a general purpose solution for running programs with more data 
than available RAM.  

	I think we ought to deal with S/W VM and H/W VM as two separate issues.
H/W VM is a general solution to times when programs need more memory than is
available.  On startup, a VM program could link into the VM manager and ask
for VM.  This task would then receive its own MMU table and could request
whatever memory it needed.  AllocMem() would need to be SetFunction()ed to
provide the necessary information to the VM manager (when swap pages to disk.)
MEMF_PUBLIC would become very important.  (Imagine your message port being
swapped out! 8^)   Internally, VM would be completely transparent, pointer
would work, etc. but communicating with other tasks could be difficult due
to different address spaces. 

	S/W VM would likely be very application dependent.  A system that
works well for an editor would likely not work for a draw program where
you want to swap out individual or collections of objects.

	On a side note, assuming that a system using systems level VM with
one address space was implemented, and swapping was only allowed in Fast RAM,
is there any easy method to determine which portions of RAM are occupied by 
non-swappable code like interrupt servers?  It would be very embarbassing to
discover the VM handler had swapped out an interrupt server code or data block
and the system came crashing down.  A second interesting situation would occur
if the swap space were assigned to a RAM drive or virtual disk that was running
under VM...

>--
>					Robert I. Eachus

=========================================================================
Eduardo Horvath				eeh@btr.com
					..!{decwrl,mips,fernwood}!btr!eeh
	"Trust me, I know what I'm doing." - Sledge Hammer
=========================================================================