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]