Article View: comp.sys.amiga.tech
Article #5550Re: Files larger than available memory.
From: Eduardo E. Horvath eeh
Date: Mon, 01 Oct 1990 17:22
Date: Mon, 01 Oct 1990 17:22
49 lines
2888 bytes
2888 bytes
In article <1089@ucsvc.ucs.unimelb.edu.au> U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes:
>G'day,
[...]
>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.
Mac's and All versions of Windows have virtual memory run by software.
The technique they use is having handles instead of pointers. Handles are
basically pointers to pointers. When you want a piece of memory, you ask the
OS for it, and the OS gives you a handle. The handle points to a table of
pointers to the actual memory you recieve. Here's a picture:
You Get OS Table Memory Blocks
-------- -------- -------------
handle ---- NULL ^ ------> Your Block
| Pointer ---- |
--> Pointer --------- Other Block
NULL
Pointer --------------> Other Block
. .
. .
To access memory you need to use double indirection. This technique is
used because the OS free to swap the pointers in the table any time. Since the
OS runs only when you make an OS call, you only need to wory about the memory
being moved around after you call the OS. This works fine for a Mac or Windows
because they don't really mutitask. On the Amiga, if you tried this technique
there is a high probability that the pointer would be changed when your task
just finished loading the pointer, but before it accessed the data. This could
be fixed either by surrounding _ALL_ accesses to memory managed data with
Forbid()/Permit() calls or only allowing re-mapping when programs call a
"O.K., you can remap my data" function. The second method will probably not
provide any memory to other progams that call AllocMem(), because there is no
guarantee that the other VM tasks will ever allow their mamory to be remapped.
This is a nasty way to cause a deadlock.
Is S/W VM really worth while?
>yours truly,
>Lou Cavallo.
=========================================================================
Eduardo Horvath eeh@btr.com
..!{decwrl,mips,fernwood}!btr!eeh
"Trust me, I know what I'm doing." - Sledge Hammer
=========================================================================
Technical Details
Message-ID:
<523@public.BTR.COM>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!decwrl!public!eehReferences:
<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>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!decwrl!public!eeh From: eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: <523@public.BTR.COM> Date: 1 Oct 90 17:22:06 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> Organization: BTR Public Access UNIX, MtnView CA, Contact: cs@btr.com 415-966-1429 Lines: 49