🚀 go-pugleaf

In article <6943@cbmvax.UUCP> thomas@cbmvax.UUCP (Dave Thomas QA) writes:

   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.

I understand completely.  I simply passed along a claim this book
made, and as such, felt compelled to at least TRY to argue the
(undeniably weak) case for their position.

   > 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.

Obviously, but it's how they seem to have interpreted it.

   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.

Fine.  But the RKM's say interrupt code and data MUST be in
MEMF_PUBLIC memory.  Why?

   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.

I fully understand the distinction between memory protection and
virtual memory.  I was just arguing a case which was lost from the
start.  And yes, virtual memory will have far less damaging effects
than memory protection, with the design of the operating system -- the
message passing mechanism, in particular.

But that wasn't the point.

Regardless, I give up.  It wasn't MY idea in the first place, and I
thought it was stupid, also.  I simply passed it along for whatever
(small) value it might have.

Geez.

Deven
--
shadow@[128.113.10.2]   <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847
shadow@[128.113.10.201] <shadow@acm.rpi.edu>  2346 15th St.    Pi-Rho America
deven@rpitsmts.bitnet   <userfxb6@rpitsmts>   Troy, NY 12180-2306  <<tionen>>
"Simple things should be simple and complex things should be possible." - A.K.