Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!cbmvax!thomas From: thomas@cbmvax.UUCP (Dave Thomas QA) Newsgroups: comp.sys.amiga.tech Subject: Re: MEMF_PHYSICAL? Message-ID: <6943@cbmvax.UUCP> Date: 22 May 89 13:43:38 GMT References: <6914@cbmvax.UUCP> Reply-To: thomas@cbmvax.UUCP (Dave Thomas QA) Organization: Commodore Technology, West Chester, PA Lines: 48 In article deven@rpi.edu (Deven Corzine) writes: > The name MEMF_PUBLIC clearly implies a relation to memory protection > (more precisely, lack thereof) yet it isn't so clearly defined. > Clearly, it implies that other tasks can access the memory, (and that > much the RKM clearly states) but what isn't clear is what effect, if > any, such a designation should mean with regards to virtual memory. It has no effect on virtual memory. Public memory is simply memory accessible to all tasks. It has nothing to do with virtual memory at all. There is absolutely no reason why public memory could not be virtual memory. > It COULD be interpreted as "any task can access the memory at any > time, so it must always be in memory." It could, but that's complicating the definition needlessly. > Of course, if a task accesses > the memory, it can be just swapped in, so that's not reason enough. > However, if you consider interrupts, the argument becomes more viable. > You can't expect the memory page to be swapped in if an interrupt > needs to access the memory; it takes too long. And all interrupt code > and data is supposed to be in MEMF_PUBLIC memory. (irregardless of > the fact that the flag is currently meaningless.) This argues that > MEMF_PUBLIC memory, beyond being publicly accessible, must also be > locked in memory, in the event that an interrupt might access it. If > you're saying that there would be an MEMF_PUBLIC flag and an > MEMF_PHYSICAL flag, totally unrelated, then how do you define the case > of interrupt code in or accessing virtual memory? Interrupt code MUST be in physical memory since interrupts must be serviced in a timely fashion. Also, interrupts on the Amiga do not really execute as part of any task and are in supervisor mode. Memory protection need not apply to them. Try to keep the concepts of memory protection and virtual memory separate in your mind. They really are two different animals. While it is true that systems which implement usually implement the other, it is not always the case. Memory protection is going to be very difficult to implement on the Amiga without breaking 99% of the programs out there, but virtual memory without protection can probably be done with much less impact on the software base. > Deven Dave -- Dave Thomas, Commodore Amiga Test Engineering UUCP ...{allegra,rutgers}!cbmvax!thomas