Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: speculative execution Message-ID: <42094@mips.mips.COM> Date: 13 Oct 90 22:54:50 GMT References: <42062@mips.mips.COM> <3445@bnr-rsc.UUCP> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 74 In article <3445@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: >In article <42062@mips.mips.COM> mash@mips.COM (John Mashey) writes: >>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. > >This should not be particularly hard, just use "volatile" in C. (I know, >the zillions of lines of existing code may break, but as some people say - >those programs are brain-damaged :-). >It is also possible for (very clever) hardware to handle it with some >sort of MMU attribute per page. Several existing processors already have >this. Speculative loads could proceed blindly until it hits one of these >stop bits. The affected load would be put "on-hold" pending a "really-do-it" >or a "forget-it". (So it's hard, but we gotta use up those millions of >transistors :-) I think we have some terminology confusion here, at least some my fault for use of term "issue". I've observed that people often note that one canot speculatively issue stores, but can so issue loads. I observed that one cannot in general "issue" loads, if you believe that "issue" actually means: run it through the cache/MMU system, and fetch from memory. I agree with the style that says: run it to the point where you realize its unsafe, then hold it until you're sure. >> 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. >This is not so. Sorry, wording again; we agree: I meant what you said ("its path"), and would have said "all paths" otherwise; "any" was imprecise. >An uncached load (at worse) stops *its* speculative path. In other words, >paths without uncached loads can still proceed. E.g., >The fetch of "somelocal" can happen before the "if". In general, after >figuring out side effects and aliasing, the only restriction should be >that volatile accesses cannot "pass" each other. > >Also, as suggested in the paragraphs above, with sufficiently clever >hardware, one can still "conservatively" speculatively fetch volatile >addresses. (Hmm, is that an oxymoron?) >> >> 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.) [..] Again, I don't think we disagree. The only real point was that there were loads, and then there were loads, and you must have some way to distinguish the ones that can be safely completed, versus the ones that cause catastrophe if they get to memory. In particular, you must especially be careful if doing a speculative-issue machine supposed to be binary-compatible at kernel level with existing machines. Such may, or may not be, a goal. thanx for the clarification; soem of my languauge was sloppy. -- -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