Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!ucbarpa.Berkeley.EDU!melvin From: melvin@ucbarpa.Berkeley.EDU (Steve Melvin) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation ( Summary: The programmer vs. the hardware: to synchronize or not to synchronize. Message-ID: <31665@ucbvax.BERKELEY.EDU> Date: 3 Oct 89 05:59:03 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: usenet@ucbvax.BERKELEY.EDU Reply-To: melvin@ucbarpa.Berkeley.EDU.UUCP (Steve Melvin) Organization: University of California, Berkeley Lines: 57 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 > I'm a little surprised that the 88K can actually do the I/O read before it knows if the multiply will generate a fault. Can you absolutely confirm this? Either way though, you have brought up a valid point, and that is that some memory mapped I/O registers may not need to be synchronized on. Certainly, a reasonable alternative to having the hardware assume all I/O reads have side-effects would be to let the programmer specify explicitly when they want synchronization and not provide it otherwise. If they expect only one read of the I/O register, the machine will still have to synchronize, but perhaps this is not always required. But this was my point. My original posting was suggesting that it is better to have the programmer explicitly let the hardware know when a read has a side-effect rather than to have the hardware discover this fact after address translation. The thing to keep in mind, however, is that in some situations it may be difficult for the programmer to know if it's "safe" not to synchronize unless the read truly has no side-effects. The processor may not yet have confirmed a branch that has been predicted many instructions back. In article <6384@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: >Since direct control over a physical IO device implies some level of >privilege, it is reasonable to require each handler to memory-lock >its pages beforehand. It is also reasonable to insist that the >handler not divide by zero (etc) within the immediate vicinity of the >IO action. Handlers don't need a "drain pipeline" instruction, if >they are not going to fault. > This is certainly a valid approach. That is, why not put the responsibility on the programmer to guarantee that no memory or arithmetic exceptions will occur in the vicinity of the I/O instruction. Then, the processor would not have to confirm outstanding memory and arithmetic operations. But faults are not the only issue. Even in the situation you propose, the hardware would still have to confirm outstanding branch predictions and it is also the case that there would have to be some sequencing control, implicit or explicit, in order to force multiple I/O reads to occur in program order. The question of exactly what is the *vicinity* gets a bit tricky also. In some situations, the vicinity might be quite large, and within the *dynamic* instruction stream, which may be difficult to know exhaustively. >As proof, I offer the working systems that are out in the world. > OK, I don't claim to know much about the real world. But I would be interested to know what systems out there work as you suggest. That is, processors that do not guarantee that a memory mapped I/O read will not take place multiple times if it is in the vicinity of an instruction that could fault. This is certainly not the case for any VAX. ------- Steve Melvin University of California, Berkeley -------