Path: utzoo!attcan!uunet!ogicse!cs.uoregon.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: speculative execution Message-ID: <42062@mips.mips.COM> Date: 11 Oct 90 20:18:47 GMT References: <1990Oct9.212103.363@rice.edu> <12905@encore.Encore.COM> <1990Oct10.164353.21070@rice.edu> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 53 In article philip@beeblebrox.dle.dg.com (Philip Gladstone) writes: ... >It is assumed in this example that none of the hoisted instructions >will cause any problems if they are executed when the programmer did >not intend them to be executed. Consider the case of overflow! I must >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). Yes, and there many subtle cases. Mike O'Dell talked about some in his talks about the Prisma machine at the last USENIX, i.e., about the exact state presented to the user upon a signal. As another example, consider the effects of hoisting a load instruction, which is something you'd like to do in a machine with out-of-order characteristics, especially if it has multiple memory paths. Here are a few cases of interest: a) The load is an uncached load to a volatile device register. Hoisting is of course a no-no, as this will drive OS programmers nuts, and in fact, must be carefully synchronized with surrounding operations, or else. So, of course, you don't hoist these things, or allow the hardware to do any hoisting for you via speculation. For instance, in the code that looks like: if (flag) x = p->device1; else y = p->device2; Any hardware that speculatively issues EITHER of the assignments before being sure which one, may well have trouble if the read actually gets to the memory system. In fact, I think this means that any uncached load stops any speculative path, because you dare not issue it for the side-effect. b) Clearly stores can't be speculatively issued. Even cached loads may take care, any time a load can cause a fault, such as an MMU miss, or an out-of-range access (like to location 0 on many machines.) A good example to always consider, evil though it may be, is the Bourne shell's expectation of fixing up a memory fault and returning to the instruction that did it... I believe this can be handled, but if there is any case that doesn't, soembody will get bitten. -- -john mashey DISCLAIMER: UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086