Hi, What is the rom code comparing against and why do we not do the delay compared to that?
If it is against the real time clock, would not nanosleep() or just polling the time be more portable? Playing games with the C memory model to acheive a certain performace seems to me to always be brittle. Peter On Fri, 27 Apr 2012, Sergey Oboguev wrote: > Hi Mark, > > The goal is to prevent smart compiler from collapsing the loops in > rom_read_delay, especially the bottom loop, by optimizing them. > Declaring "loopval" as volatile does just that, by effectively disabling > compiler's capability to optimize, and does it in a portable way. > > Disabling inlining of rom_swapb, in fact, does not provide such guarantee > long > term. > It may shut off compiler's optimizations today, but once the compiler (or > compilers) gets even smarter in the future, it can some day figure out the > code > "does not need" to call rom_swapb. > Compiler may leave the function un-inlined, but just figure out it does not > need to be called and optimize the whole loop construct away. > > Therefore volatile is both portable and -- long-term -- safer approach. > The caveat is, compilers do have bugs and can sometimes disregard volatile > declaration. > See for ex. "Volatiles Are Miscompiled, and What to Do about It" > http://dl.acm.org/citation.cfm?id=1450093 > Note that in older versions of LLVM used to be a particularly bad offender, > miscompiling (in LLVC-GCC version 2.2) 19% of volatile references, however > it > got better since then. > > So when using volatile it's worth to take some extra steps that reduce > probability of triggering compiler's bug, particularly avoiding declaring > variable in question as local scope. > Or, perhaps even better, what Eide & Regehr suggest in the mentioned article: > instead of accessing variable directly, perform accesses via via per-type > accessor routines. Or both. > > Thanks, > Sergey _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
