Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!ub.d.umn.edu!rutgers!usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: speculative execution Summary: A better way to manage esceptions? Message-ID: <2674@l.cc.purdue.edu> Date: 23 Oct 90 12:44:16 GMT References: <2772@crdos1.crd.ge.COM> <3483@bnr-rsc.UUCP> Organization: Purdue University Statistics Department Lines: 49 In article <3483@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes: > In article <2772@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: > >In article rbw00@JUTS.ccc.amdahl.com ( 213 Richard Wilmot) writes: > > > >| Please NO. Save me from deferred traps. The CDC 6600 and some others > >| could produce several FP results that were illegal values FOR ANY OTHER > >| OPERATIONS. So exception traps took place not when/where you produced the > >| result but later when you tried to use it. Then the game was to guess where > >| you produced this value. .................... > There is another way. Assuming one wanted to allow speculative execution > and don't want traps gumming up the works, one could have traps happen > at *assignment*. This means each stage of the (say the FPU) pipe could > generate a "Trap Flag". This flag would be propagated through each stage > and finally causing a trap when you try to catch value from the exit end > of the pipe. > > Possible refinements include not trapping if catching into r0 (or other > "non-real" registers); making the trap flag include the trap reason and > or stage that caused the trap. > > It seems to me this solves the problem (of traps gumming up speculative > execution) and is more debuggable than many architectures. We need more, not less, user control. The reasonable programmer knows what the program is doing, what odd things should occur, and what apparently odd things should be ignored. Not being ominiscient, the programmer will miss a few. The "optimal" thing to do would be to have these handled efficiently in accordance with the available information. To do this efficiently would require the appropriate hardware for traceback, and a rarely used part of the instruction to handle the enabling and disabling of traps, what to do if they occur, etc. Many architectural problems and considerations are involved here, but every simple solution proposed runs into problems. It is quite possible, even, that some traps can be anticipated and thereby avoided. I have not seen any such architectural features. One example of this is buffer read and call a refill procedure when empty. The reads are sporadic. Now an anticipatory procedure would issue a weak interrupt when the last item is read, but a strong interrupt if an attempt is made to read when the buffer is empty. Similar things can occur with arithmetic and logical conditions. Attempts to oversimplify the problem are not likely to be optimal. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)