Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: speculative execution Keywords: deferred traps, abomination Message-ID: <2772@crdos1.crd.ge.COM> Date: 17 Oct 90 20:25:31 GMT References: <1990Oct9.212103.363@rice.edu> <12905@encore.Encore.COM> <1990Oct10.164353.21070@rice.edu> <22587@grebyn.com> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 21 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. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.