rogue@cellar.UUCP (Rogue Winter) (04/13/91)
Deliberately not following any of the above, I think it's best to describe the difference between ++i and i++ as follows: ++i Increment i and use the new value in expression (calculation). i++ Use [old] value of i in expression and THEN increment. All this talk about discarding values is confusing and misleading. i retains its value until the function is exited (assuming i is local). rogue winter : "Never trust a gentleman any further than you can throw rogue@cellar.uucp: his valet."
bhoughto@hopi.intel.com (Blair P. Houghton) (04/17/91)
In article <5ywa15w164w@cellar.UUCP> rogue@cellar.UUCP (Rogue Winter) writes: >++i Increment i and use the new value in expression (calculation). >i++ Use [old] value of i in expression and THEN increment. >All this talk about discarding values is confusing and misleading. i retains >its value until the function is exited (assuming i is local). Yes, you're right, most of it is moot, but remember that the entire operation is permitted to be "discarded" if the value of i is never used again in the rest of its current scope. --Blair "Optimization is irrelevant because it is not prohibited..."
peter@ficc.ferranti.com (Peter da Silva) (04/18/91)
In article <3845@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes: > Yes, you're right, most of it is moot, but remember that > the entire operation is permitted to be "discarded" if > the value of i is never used again in the rest of its > current scope. ... and if i isn't volatile ... -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?" Shouldn't that be "if I aren't volatile"?
mwizard@eecs.cs.pdx.edu (Craig Nelson) (04/19/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >In article <3845@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes: >> Yes, you're right, most of it is moot, but remember that >> the entire operation is permitted to be "discarded" if >> the value of i is never used again in the rest of its >> current scope. > ... and if i isn't volatile ... >-- >Peter da Silva. `-_-' peter@ferranti.com >+1 713 274 5180. 'U` "Have you hugged your wolf today?" >Shouldn't that be "if I aren't volatile"? Boy, did I start a "nasty" or what ? This will sound kinda stupid but I actualy tried this on a 4.2 BSD machine about three years ago. I know it won't sound right, but you know what it did ? Nothing, not a damn thing happened to i. it just blew it over. Cheers! []====================================================================[] || Craig R. Nelson | CCSofD Software Inc. || || Programmer | Beaverton, OR, 97005 || || mwizard@eecs.ee.pdx.edu | (unlisted on the net) || ||====================================================================|| || The opinions expressed here are mine. No one gave them to me. || || Since I own half of it they are also the company's opinons. || || (but only fifty-percent of the time.) || []====================================================================[] []====================================================================[] || Craig R. Nelson | CCSofD Software Inc. || || Programmer | Beaverton, OR, 97005 || || mwizard@eecs.ee.pdx.edu | (unlisted on the net) ||
bhoughto@pima.intel.com (Blair P. Houghton) (04/20/91)
In article <FGTAV-9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <3845@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes: >> Yes, you're right, most of it is moot, but remember that >> the entire operation is permitted to be "discarded" if > > ... and if i isn't volatile ... Nope. A volatile declaration implies only that a side effect occurs whenever the variable is named (accessed) whether you're reading or writing it (i.e., whether it's in an rvalue or lvalue context). If the compiler's smart enough to understand that the "side effect is not needed" (q.v., somewhere in ANSI X3.159-1989; you can use the rest of the book to define what "needed" means) and the value is not used, then the evaluation can be elided. It'd have to be a pretty dang smart compiler, though... --Blair "If you can detect no difference, then there is no difference." - Houghton's Indeterminacy Corollary to Heisenberg's Uncertainty Principle
peter@ficc.ferranti.com (Peter da Silva) (04/23/91)
In article <3924@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes: > In article <FGTAV-9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >In article <3845@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes: > >> Yes, you're right, most of it is moot, but remember that > >> the entire operation is permitted to be "discarded" if > > ... and if i isn't volatile ... > If the compiler's smart > enough to understand that the "side effect is not needed" > and the value is not used, then the evaluation can be elided. I'd hate to have to write a device driver with that compiler, mate. A compiler that sharp can cut you. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?" So you're volatile too?
bhoughto@pima.intel.com (Blair P. Houghton) (04/24/91)
In article <B_WAUIB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <3924@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes: >> If the compiler's smart >> enough to understand that the "side effect [of a ref. to a >> volatile object] is not needed" and the value is not used, >> then the evaluation can be elided. > >I'd hate to have to write a device driver with that compiler, mate. >A compiler that sharp can cut you. I'd _love_ to have a compiler that knows all about my new, still-in-the-box devices' needs. YADDPG: Yet Another Device Driver Program Generator. It'd sure cut down on hand-packing arrays... :-) No, seriously, I doubt very much that accessing a previously undefined location would be something this whiffy-compiler could optimize out. One common one, though, might be if a compiler eliminated the setting of `a' and the call to free() in void foo() { volatile char *a; free(a=0); exit(0); } Since you're setting `a' -- creating a side-effect -- the implementation must arrange that the machinery not alter `a' -- create another side-effect -- before the call to free(); hence, free() is guaranteed to be called with argument (char *)0, a null pointer, and thus is defined to have no effect. Here it's obvious that foo() is synonymous with `{volatile char *a=0;exit();}' if the compiler believes it, the the call to free() may, obviously, be removed. If it can also determine that assigning 0 to `a' is irrelevant to the machinery, the declaration and assignment may also be removed. exit() will never get removed, although the call to foo() (in the calling routine) may be turned into a call to exit(0), again if the implementation is on its toes and it doesn't materially change the effect in the calling routine. Any optimization you can do by hand can be done by a compiler. >So you're volatile too? Some call it "temperamental." --Blair "Some call it 'viscous...'"
sef@kithrup.COM (Sean Eric Fagan) (04/26/91)
In article <B_WAUIB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >I'd hate to have to write a device driver with that compiler, mate. >A compiler that sharp can cut you. That's the exact reason 'volatile' exists. You, as the programmer, know whether or not some memory location needs to be accessed, or whether a spin-loop (gag) needs to be there. I *like* my compiler to, at times, spend lots of cycles doing loop unrolling and elimination. It can be very useful at times. But, then, you do need some way of saying "can't touch this," which is what volatile provides, no? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jon@maui.cs.ucla.edu (Jonathan Gingerich) (04/26/91)
May accessing a volatile cause external (to the program) changes? If so, then it could never be optimized out. Jon.
gwyn@smoke.brl.mil (Doug Gwyn) (04/27/91)
In article <1991Apr25.190127.8178@cs.ucla.edu> jon@maui.cs.ucla.edu (Jonathan Gingerich) writes: >May accessing a volatile cause external (to the program) changes? Yes, but that's not relevant. Even accessing a non-volatile could do that. >If so, then it could never be optimized out. That's the requirement for accesses to volatiles anyway.
bhoughto@pima.intel.com (Blair P. Houghton) (04/27/91)
In article <1991Apr25.174310.21264@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >I *like* my compiler to, at times, spend lots of cycles doing loop unrolling >and elimination. It can be very useful at times. But, then, you do need >some way of saying "can't touch this," which is what volatile provides, no? Yes, you do need it, and yes, `volatile' is a hint to the compiler that you know which variables are sticky and which are just your verbosity going nuts, but there's a footnote (67) at the bottom of one page (65) of the standard (ANSI X3.159-1989) that says maybe it won't be so sticky. Of course there's lots in there to indicate this may not have been the true intent of the committee, but once again the words in print don't bear that out. --Blair "I need to wash up."