Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!dogie.macc.wisc.edu!csd4.milw.wisc.edu!lll-winken!arisia!sgi!shinobu!odin!sgi.com!scotth From: scotth@sgi.com (Scott Henry) Newsgroups: comp.sys.amiga.tech Subject: Re: Virtual Memory / compatibility Message-ID: Date: 19 May 89 08:16:59 GMT References: <8905182025.AA00096@loki.pmel.edsg.hac.com> Sender: news@odin.SGI.COM Reply-To: scotth@sgi.com Organization: Silicon Graphics Inc, Mountain View, CA Lines: 55 In-reply-to: suggs@loki.pmel.edsg.hac.COM's message of 18 May 89 20:25:53 GMT b>Matt Dillon writes: b>> ... Certainly I would much rather b>> have a MEMF_PHYSICAL flag instead of a MEMF_VIRTUAL flag, but it would break b>> too many programs ... I am wondering, how would it break most application programs? (See my note below). I can understand problems with handlers (like dmouse/qmouse, etc), but why would there be a problem with application programs? b>My two cents: b>It seems that even those advocating MEMF_VIRTUAL agree that MEMF_PHYSICAL is a b>better way (exept for maintaining compatability.) b> b> [...deleted...] b> b>As someone poined out in a previous posting, b> b> main(){printf("Hello World!\n");} b> b>is a multitasking program on a "proper" multitasking OS. b> b>It should also run in virtual memory *by default* b> b> b>OK now everyone tell me why I'm wrong... b> I would say that you are not wrong. The intent (as I understand it) behind virtual memory, is that it looks (to the programmer/user) as a larger physical address space, and is indistinguishable (except possibly for performance) to having all physical memory. Locality and frequency of reference would keep "important" pages in physical memory. Since not all Amigas will be expected to have VM (similarly that not all Amigas currently have Fast RAM), somebody would need to write a "fixVMhunk" program, analogous to the current (and hopefully soon to be deceased, as all programmers FINALLY know the difference) fixhunk program for fast/chip RAM. So that if, for example, you have your brand new Amiga 3600 w/VM, and would rather use dmouse1.10 (which doesn't know about MEMF_PHYSICAL) instead of the latest dmouse 3.55 :-) which does, why, just fixVMhunk it! Because VM is *supposed* to be transparent for most (application) programs, and certainly for most code, I think using MEMF_PHYSICAL, along with a fixVMhunk-type program to fix-up errant programs would be the compatible way to go. Note that I don't expect to get VM for CHIP RAM, only FAST RAM, though this scheme should still work for that, also. Maybe Commodore should add the MEMF_PHYSICAL flag to 1.4, even though it wouldn't do anything, just so that it documented well ahead of time... -- --------------------- Scott Henry #include