Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!uupsi!grebyn!ckp From: ckp@grebyn.com (Checkpoint Technologies) Newsgroups: comp.arch Subject: Re: speculative execution Message-ID: <22587@grebyn.com> Date: 12 Oct 90 16:18:01 GMT References: <1990Oct9.212103.363@rice.edu> <12905@encore.Encore.COM> <1990Oct10.164353.21070@rice.edu> Reply-To: ckp@grebyn.UUCP (Checkpoint Technologies) Organization: Grebyn Timesharing, Vienna, VA, USA Lines: 30 In article philip@beeblebrox.dle.dg.com (Philip Gladstone) writes: >This whole problem arises from the fact that most instructions have an >implicit conditional branch (interrupt) as part of their >specification. You can only (reliably) hoist instructions that cannot >trap -- unless you can perform major flow analysis to check that the >trap conditions never arise (such as adding two shorts in long >registers with an overflow causing instruction). > >Removing the implicit trapping action of these instructions would be a >way out of this problem, but you would have to introduce some sort of >'trap on previous overflow' instruction. Even then you would have to >take great care that you only detected the right overflows. #pragma MY_TWO_CENTS Forgive my insolence - I'm not an architecture designer, be gentle with me, but this just occured to me.. Why not include condition code bits with each register? Store these when the register value is stored, when it pops out the end of a pipeline. Include a flag for NAN (not a new idea, right?), and store this for things like divide-by-0. Then you can trap when the register is used as a source operand, and you can code explicit tests (and maybe traps) when you want to, on operations that could very well be taking place simultaneously. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/