Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucla-cs!oahu!marc
From: marc@oahu.cs.ucla.edu (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation (
Message-ID: <27659@shemp.CS.UCLA.EDU>
Date: 3 Oct 89 16:58:50 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <2451@wyse.wyse.com> <477@ctycal.UUCP> <265@ssp1.idca.tds.philips.nl> <4796@orca.WV.TEK.COM>
Sender: news@CS.UCLA.EDU
Reply-To: marc@oahu.UUCP (Marc Tremblay)
Organization: UCLA Computer Science Department
Lines: 28

In article <4796@orca.WV.TEK.COM> andrew@frip.wv.tek.com writes:
>By way of counter-example:  the M88k has a lot of pipelining, and some
>of the floating-point exceptions are imprecise.  I might very well have
>code like this:
>
>	fmul.sss	r2,r3,r4	; start a floating multiply
>	ld		r5,r6,0		; start an I/O read
>
>and, while the load is underway, the FPU decides to fire off a floating
>underflow exception.  That's fine, I expected this and my floating
>exception handler substitutes zero, cleans out the pipes, and returns.
>I don't need to idle for four cycles waiting for the multiply to finish
>just on the rare chance that it will underflow.

Notice that these two instructions do not have any control or data
dependencies. The load could have been executed before the floating 
point multiply and the result would have been the same.
So in this example it really doesn't matter (for the exception
routine) if ld is executed before fmul.sss!

Problems would occur if instructions occurring after the "faulty" instruction
modify registers needed in the exception routine.
Fortunately the 88000 provides special registers which contain the
necessary information for the software to complete an instruction
that caused an imprecise exception.

					Marc Tremblay
					marc@CS.UCLA.EDU