Andrew Poelstra wrote:
>
> 2. If you're just counting clock cycles, the 'volatile' specifier
> should prevent gcc's loop optimizations, no?
>
> int count(volatile int n)
> {
> while(n--)
> ;
> }

I wouldn't bet on that. It will definitely not help against
reordering[1]. An asm-statement is better:

inline void
delay(int n)
{
    while (n--)
        __asm__ __volatile__("nop" : : : "memory");
}

But I would strongly suggest to write a simple assembler routine
to give reliable results. These compiler generated busy loops
depend heavily on compiler optimization and may easily take a
couple of times longer/shorter then expected (i.e. a delay(10)
may take anything between 10 or 100 clock cycles; developer tests
with -O1 and in release build with -O3 everything breaks).

Ciao, ET.

[1]: I.e. this code:

        mem++;
        delay(10);
        mem++;

may be optimized to

        delay(10);
        mem += 2;

if the compiler finds out that delay() doesn't depend on mem.

I just hope that all memory mapped I/O accesses are properly
pretected against this (via volatile keyword or memory barriers).
Writing low-level code has become really hard with these highly
optimizing compilers ;-)
Received on 2010-06-15