Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ogccse!blake!milton!uw-beaver!ubc-cs!alberta!calgary!ctycal!ingoldsb From: ingoldsb@ctycal.COM (Terry Ingoldsby) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation ( Summary: Depends on the OS?? Message-ID: <480@ctycal.UUCP> Date: 1 Oct 89 22:59:57 GMT References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <2255@munnari.oz.au> Organization: The City of Calgary, Ab Lines: 41 In article <2255@munnari.oz.au>, ok@cs.mu.oz.au (Richard O'Keefe) writes: > 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 > > 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. > Granted, it could happen under some conditions. I was thinking more of the case where the user doesn't actually do the memory access, but rather makes a system call for the OS to do it. Many OSes lock things like disk device drivers, buffer space, tables, etc. into memory and I assumed that many OSes would do the same with the memory locations corresponding to devices. This wouldn't be hard to do since a small region of memory could be dedicated to this. Whether this is done or not I have no idea (any OS gurus out there know how it really is done?). Nonetheless, it doesn't make any difference since the instructions I suggested still work even if the fault occurs. The only thing that I can see happening if the page is not locked into memory is if a swapper tries to write a region of memory out to disk. That could provoke some unusual behaviour of the peripherals! A similar argument would exist for swapping (or paging - if it is a hard page fault) the region back into memory. Soft page faults (ie. those where the page is in physical memory, but not in a process's page table) just involve setting up some pointers and don't actually affect (ie. read/write) the memory locations. Is any of this making sense? -- Terry Ingoldsby ctycal!ingoldsb@calgary.UUCP Land Information Systems or The City of Calgary ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb