[Simh] clang (was Re: XCode and LTO)

[Peter Svensson]

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