Path: utzoo!attcan!uunet!wuarchive!psuvax1!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Files larger than available memory.
Message-ID: <14817@cbmvax.commodore.com>
Date: 2 Oct 90 19:56:21 GMT
References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <83986@tut.cis.ohio-state.edu> <14646@cbmvax.commodore.com> <MWM.90Sep25180852@raven.pa.dec.com> <1089@ucsvc.ucs.unimelb.edu.au>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 48

In article <1089@ucsvc.ucs.unimelb.edu.au> U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes:

>I believe that I read that some (all) Mac s/ware for non MMU capable Macs can
>page memory (I don't know first hand, sorry) and similarly for Windows 3.0. I
>am not one of those "they have, we should have it" cry babies however. I just
>think it makes sense.

I'm not quite sure how much the Mac uses its tricks to swap out to disk, but
I did read up on what they do.  Basically, there's a memory allocation function
that returns a memory handle, which is essentially a pointer to a pointer to
a chunk of memory.  If you lock the handle, it doesn't move, but if you
unlock it, it can be relocated.  The main idea in the article I read (probably
in Dr. Dobbs or BYTE, at least a year or two ago) was that this mechanism 
prevented memory fragmentation by making chunks of allocated memory movable.

>My thoughts are that if all s/w writers could choose to support a mem. paging
>(Dave Haynie suggests a swapping library) system that nonMMU (hence virt. mem
>Amiga OS support..one day) Amiga owners would have more choice in s/w and RAM
>configurations.

There are quite a few systems that use or lend themselves to using a number
of memory blocks.  Like text editors and the like.  If you implemented some
kind of memory handle library for the Amiga, it could be based on a system of
handles.  A function call initializes a handle list/array with the path name
of a backup device, the optional maximum number of blocks in the array, 
optional maximum number of blocks in memory at one time, and the block size.  
Blocks initially point to nothing.  You obtain access to a block by locking 
it, and relinquish access by unlocking it.  No pointers are permitted to 
the contents of an unlocked block, though the block itself may be referenced
via a pointer.

While such a scheme isn't as nice as true virtual memory, it does have some
advantages.  It'll work on a plain 68000 system, in which the library calls
use normal AmigaDOS Read()/Write() to perform the swapping, manage a pool 
of real memory buffers, etc.  In an MMU based system without OS management of
the MMU, a real system could be implemented, with the library performing the
actual swap routines as blocks are locked and unlocked.  On an Amiga with
real virtual memory, a block is simply allocated as a chunk of MEMF_VIRTUAL
when it's first locked, freed when the block array is closed, and the block
free function becomes a no-op.

>Lou Cavallo.


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	Standing on the shoulders of giants leaves me cold	-REM