Path: 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> <1089@ucsvc.ucs.unimelb.edu.au> Organization: BTR Public Access UNIX, MtnView CA, Contact: cs@btr.com 415-966-1429 Lines: 49 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 =========================================================================