On Apr 27, 2012, at 2:52 PM, Mark Pizzolato - Info Comm wrote: > On Friday, April 27, 2012, at 10:44 AM, Sergey Oboguev wrote: >> Declaring "loopval" as volatile (and perhaps global, rather than on-stack, to >> reduce chances of compiler disregarding volatile declaration) might do the >> trick. > > The goal really isn't to cause a memory reference, but really to avoid the > inlining on this specific function. We're trying to do enough 'spinning' to > slow things down predictably here.
Doesn't it amount to the same thing? If the function gets inlined, then a subsequent optimization step may realize loopval never changes and eliminate even the inlined function calls. Preventing inlining prevents that. But making loopval volatile is like saying it's a device register or something that can be changed from outside of the program, right? So that also prevents it from optimizing out references to loopval (even if the function it's passed to gets inlined) since the compiler doesn't know when it might change. This is speculative as I haven't tried to analyze any assembler listings (and they don't always reflect exactly what the optimizer did), but I suspect that's the gist of it. In other words, I'm not sure if it matters much which way we go, especially since I *think* this code is just involved with spinning up the virtual ROM and doesn't do much after the simulator is up and running. ________________________________________ Craig A. Berry mailto:[email protected] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
