Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!noao!asuvax!behemoth!mph
From: mph@behemoth.phx.mcd.mot.com (Mark Huth)
Newsgroups: comp.sys.amiga
Subject: Re: OS/2 vs AmigaDOS
Message-ID: <10850@behemoth.phx.mcd.mot.com>
Date: 5 May 89 00:18:15 GMT
References: <16952@usc.edu> <7988@killer.Dallas.TX.US> <6758@cbmvax.UUCP>
Reply-To: mph@behemoth.UUCP (Mark Huth)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 29

In article <6758@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>... stuff about VM/protection - VM not too hard...
>	Actually, it's tougher than that.  Forbid()/Permit() locking is no
>longer sufficient if you need to take a page fault in the middle of it.
>Let's not talk about Disable/Enable.

Well, I don't really see a problem with Forbid/Permit.  If I recall
correctly, Forbid forbids task switching.  VM doesn't get in the way
of this, but the processor does get kinda' bored waiting for the page
to swap into physical memory.  Of course, the use of VM makes
execution times much less predictable.  If there is an upper bound on
the time forbid is allowed, then the VM system taking a page fault may
violate that constraint.

Disable is another game all together.  If disable only affects the
software interrupt to a particular task/process (that is, if we're
talking virtual interrupts) then VM makes no difference.  If on the
other hand, we're talking about raising the interrupt level mask to 7
in the SR, that's a completely different story.  Normally, code which
must disable critical interrupts in a VM system will run
untranslated, or have its physical pages locked in memory so as to 
bound the disable time.  This is what drivers and other pieces of
trusted software are for.

Basically, virtual memory systems are transparent to the virtual
machine user.  Those who use the physical machine gotta' take a little
more care.

Mark Huth