Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation (
Message-ID: <2255@munnari.oz.au>
Date: 30 Sep 89 07:10:12 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <477@ctycal.UUCP>
Sender: news@cs.mu.oz.au
Lines: 25

In article <477@ctycal.UUCP>, ingoldsb@ctycal.COM (Terry Ingoldsby) writes:
> As an alternative, do the following:
>     MOV       addr1,R1      (ie Move data found at addr1 into register R1)
>     STO       R1,addr2      (store register contents in addr2)
> Even if the fault occurs during the read of addr1 (a bit odd since
> peripheral memory locations are usually non-pageable) then the access will
> still only occur once.  If the page fault occurs during the store then
> we similarly don't care since addr2 will also only be accessed once (in my
> example it's just memory but could conceivably be another peripheral).

It doesn't sound all that unreasonable for a page fault to occur during
a memory-mapped I/O operation.  Imagine a memory-mapped scheme where each
device has all its registers in a different page of I/O space, and where
the operating system is running a "virtual machine" scheme.  All I/O
pages would initially be mapped out of a process's address space.  Touching
an I/O page would cause a page fault, at which time the O/S would check
whether the process had permission to access that device, and if so would
map the page in.  If the O/S needed to seize control of the device back,
it would map the page out again.

Whether such a scheme is useful or not is another matter.
-- 
GNUs are more derived than other extant alcelaphines,| Richard A. O'Keefe
such as bonteboks, and show up later in the fossil   | visiting Melbourne
record than less highly derived species.  (Eldredge) | ok@munmurra.cs.mu.OZ.au