Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!xylogics!bu.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: speculative execution Message-ID: <2657@l.cc.purdue.edu> Date: 19 Oct 90 12:36:48 GMT References: <12976@encore.Encore.COM> Organization: Purdue University Statistics Department Lines: 29 In article <12976@encore.Encore.COM>, jkenton@pinocchio.encore.com (Jeff Kenton) writes: > From article , by rbw00@ccc.amdahl.com ( 213 Richard Wilmot): > > 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. > What you are describing is fairly close to the idea of NaN (Not a Number) > required by the IEEE spec for floating point calculations. The operation > which produces a NaN ( 0/0, infinity - infinity, inf / inf ) *will* trap > when it occurs, but the NaNs will trap when they are used (if the trap > is enabled). The 6600 was really RISCy, and had no provision whatever for optional traps. These conditions were testable, however, and many algorithms did such tests. It was also hoped that the increased exponent range would decrease the occurrence. These results were only illegal in FP operations. One way this trap was used as a feature was to initialize memory to negative indefinite (not produced by any FP operation) to detect when it was read before being written. BTW, these traps could be turned off globally. -- 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)