Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!gatech!unmvax!bbx!bbxeng!scott From: scott@bbxeng.UUCP (Engineering) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation Message-ID: <205@bbxeng.UUCP> Date: 28 Aug 89 20:29:59 GMT References: <1989Aug24.215104.156@mentor.com> <231@ssp1.idca.tds.philips.nl> <2345@oakhill.UUCP> <204@bbxeng.UUCP> <5990@pt.cs.cmu.edu> Reply-To: scott@bbxeng.UUCP (Scott-Engineering) Organization: Basis International, Albuquerque, NM Lines: 27 In article <5990@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: > >If the hardware has been designed to do "instruction continuation", >then the user program will resume somewhere in the middle of the >offending instruction. If the hardware has been designed for >"instruction restart", then the program will be resumed at the start >of the offending instruction. The user-visible result is the same in >both cases. > I guess this is where I'm having a problem. What if the instruction involved address increment/decrement modes? Restarting the instruction might not give the exact same result unless the results of auto-inc/dec were not placed into the affected registers until the instruction completes. I remember reading some literature when the 68010 came out explaining the wonderful benefits of instruction continuation and why instruction restart did not always solve the problem. (I don't remember *where* I read this.) Now I'm hearing that it doesn't really matter. Instruction restart makes a lot more sense to me as long as the side effects of the instruction are not not interruptable. Is this the case with the 68040? -- --------------------------------------- Scott Amspoker Basis International, Albuquerque, NM 505-345-5232