Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation
Message-ID: <6466@pt.cs.cmu.edu>
Date: 10 Oct 89 02:17:20 GMT
References: <20260@usc.edu> <487@ctycal.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 35

In article <487@ctycal.UUCP> ingoldsb@ctycal.UUCP (Terry Ingoldsby) writes:
>In article <20260@usc.edu>, vorbrueg@bufo.usc.edu (Jan Vorbrueggen) 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)
>> But what if the pagetables mapping addr1 or addr2 are pageable?
>
>Sorry, I'm not quite following how this anything.  ie. why will that
>make addr1 or addr2 get accessed more than once?

The worst that can happen is that processing the STO will cause a
fault, after the MOV has already started its memory read, and before
the MOV has completed.

There are four ways out of that situation:

1) Abort the MOV and restart it later. This is the dreaded Bad Thing.

2) The hardware can finish the outstanding instruction before honoring
   the fault.

3) The data read from memory can be latched, and the fault handler
   can rationalize things.

4) My personal favorite: "Then don't do that." Either faults are OK,
   or they aren't. If they aren't, then the code segment should be
   memory locked. Locking the page table entries should be an
   automatic consequence of getting the OS to lock the pages.



-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science