Xref: utzoo comp.arch:10695 comp.misc:6586
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,comp.misc
Subject: Re: long instructions & page faults
Keywords: page fault fetchahead
Message-ID: <5567@pt.cs.cmu.edu>
Date: 18 Jul 89 20:58:12 GMT
References: <32424@apple.Apple.COM> <226@arnor.UUCP> <33015@apple.Apple.COM> <29418@ism780c.isc.com> <1449@mdbs.UUCP> <18766@sequent.UUCP> <42835@bbn.COM>
Organization: Carnegie-Mellon University, CS/RI
Lines: 17

Another fun one is what happens when instruction fetchahead 
pagefaults. 

- the program may branch before it uses the page, thus you've wasted
  the cycles.
- the program may branch before it uses the page, thus making any
  horrendous error condition into a non-error that you must not
  report.
- the pipeline conditions are different from the pipeline conditions
  during a faulted load/store. Hence, if you take these faults, then
  the fault handler has to be able to tell the difference, and has to
  be able to restore to the correct state.

Early models of the IBM PC/RT had a hardware bug in this area. They 
patched it (on that model) by suppressing fetchahead.
-- 
Don		D.C.Lindsay 	Carnegie Mellon School of Computer Science