Path: utzoo!utgpu!cunews!bnrgate!bigsur!bnr-rsc!bcarh185!schow From: schow@bcarh185.bnr.ca (Stanley T.H. Chow) Newsgroups: comp.arch Subject: Re: speculative execution Message-ID: <3483@bnr-rsc.UUCP> Date: 17 Oct 90 21:50:48 GMT References: <2772@crdos1.crd.ge.COM> Sender: news@bnr-rsc.UUCP Reply-To: bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) Organization: BNR Ottawa, Canada Lines: 39 Summary: Followup-To: Keywords: 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. > > It depends on how the system is designed. If I were designing a CPU >(and I don't), I would allow parallelism by allowing the FPU to have a >delay mode in which an instruction, let's call it DTRAP, sets a flag >such that if a trap would occur, the FPU enters a wait state until the >CPU issues the sync instruction, say WAIT, at which point the trap >occurs. > > This assumes that either you don't care about pinpointing the problem, >or you have some hook in the FPU to report it in a meaningful way. >Obviously you want an ITRAP for immediate trapping in other cases. 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. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!uunet!bnrgate!bcarh185!schow (613) 763-2831 ..!psuvax1!BNR.CA.bitnet!schow Me? Represent other people? Don't make them laugh so hard.