Article View: comp.sys.amiga.tech
Article #12790Re: MEMF_PHYSICAL?
From: Dave Thomas QA
Date: Mon, 22 May 1989 13:43
Date: Mon, 22 May 1989 13:43
48 lines
2973 bytes
2973 bytes
In article <DEVEN.89May19053755@daniel.rpi.edu> 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
Technical Details
Message-ID:
<6943@cbmvax.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!cbmvax!thomasReferences:
<DEVEN.89May18024329@daniel.rpi.edu> <6914@cbmvax.UUCP> <DEVEN.89May19053755@daniel.rpi.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <DEVEN.89May18024329@daniel.rpi.edu> <6914@cbmvax.UUCP> <DEVEN.89May19053755@daniel.rpi.edu> Reply-To: thomas@cbmvax.UUCP (Dave Thomas QA) Organization: Commodore Technology, West Chester, PA Lines: 48