Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@crhc.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: speculative execution Message-ID: Date: 18 Oct 90 20:28:09 GMT References: <2772@crdos1.crd.ge.COM> <3483@bnr-rsc.UUCP> Sender: news@ux1.cso.uiuc.edu (News) Organization: Center for Reliable and High-Performance Computing University of Illinois at Urbana Champaign Lines: 12 In-Reply-To: schow@bcarh185.bnr.ca's message of 17 Oct 90 21:50:48 GMT >| 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. Why not split the expensive possibly trap produciung instruction into two parts: (1) expensive, deferred trap producing instruction that is percolated upwards and speculatively executed; and (2) an inexpensive instruction that takes the deferred trap and actually produces an immediate trap, and is not subjected to code motion? -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]