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