Why does the naive delay in chapter 9 require a NOP, but the timer-based delay does not?

[JackNWhite]

If you remember, the original delay function is:

fn naive_delay(tim6: &tim6::RegisterBlock, ms: u16)
{
    const K: u16 = 3;

    for _ in 0..(K * ms)
    {
        aux9::nop();
    }
}

And the final function is:

fn delay(tim6: &tim6::RegisterBlock, ms: u16)
{
    tim6.arr.write(|w| w.arr().bits(ms));
    tim6.cr1.modify(|_, w| w.cen().set_bit());

    while tim6.sr.read().uif().bit_is_clear()
    {
        // aux9::nop();
    }

    tim6.sr.modify(|_, w| w.uif().clear_bit());
}

I have checked the debug and release builds for both, and the former, as you find in the book, works only under debug conditions, while the latter works under both debug and release conditions. I don't see why the compiler would make the distinction.

[sirhcel]

Typical release builds will turn on compiler optimizations which perform a semantically equivalent transformation of your input program. As the nop does not contribute to any computation result, it could be eliminated from the compiler's perspective who explicitly is about to alter timing behaviour for the "better".

You have to take special measures to protect such an instructrion from being optimized away.

When checking whether the timer has been elapsed, the magic is already built it. This bit is declared to be externally modified so that the compiler does not assume the value it reads for the first time will be there forever (as its code does not manipulate it).