Article View: comp.arch
Article #2418Re: Instruction (dis)continuation (
From: Terry Ingoldsby
Date: Sun, 01 Oct 1989 22:59
Date: Sun, 01 Oct 1989 22:59
41 lines
3117 bytes
3117 bytes
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
Technical Details
Message-ID:
<480@ctycal.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ogccse!blake!milton!uw-beaver!ubc-cs!alberta!calgary!ctycal!ingoldsbReferences:
<2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <2255@munnari.oz.au>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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