Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!zephyr.ens.tek.com!orca!frip!andrew From: andrew@frip.WV.TEK.COM (Andrew Klossner) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation ( Message-ID: <4796@orca.WV.TEK.COM> Date: 2 Oct 89 21:30:44 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> Sender: nobody@orca.WV.TEK.COM Reply-To: andrew@frip.wv.tek.com Organization: Tektronix, Wilsonville, Oregon Lines: 29 [] "The bottom line for an I/O instruction is that it represents a synchronization point from the perspective of the hardware. That is, all unconfirmed operations have to be verified before the I/O operation can take place." This is a sufficient but not a necessary condition. It's more restrictive than it needs to be. 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. If for some reason I want synchronization, I'll use the provided instructions to suspend execution until all the pipelines have drained. But I don't need to do this on every I/O op. -=- Andrew Klossner (uunet!tektronix!frip.WV.TEK!andrew) [UUCP] (andrew%frip.wv.tek.com@relay.cs.net) [ARPA]