Re: [avr-gcc-list] Re: Optimisation of bit set/clear in uint32_t

[Paulo Marques]

Hi, Dale

Dale Whitfield wrote:
> I replied to some of these points in David's post.
> 
> And yes, I agree its probably more about staying close to 8-bit
> operations than anything else.
> 
> Reads or writes, I believe, can be removed when updating a volatile that
> is greater than 8-bits. 

Dale, this has nothing to do with "beliefs" or "philosophical"
questions. It is all about _C standards_.

If the standard says that a read or a write to a volatile variable can
not be removed by the compiler, then that's what the compiler must do to
be standards compliant. No ifs, buts or maybes about it.

The example David Brown pointed out with the timer is a perfectly fine
example, because the timer is "memory mapped". So, for the compiler ram
bytes or timer registers are the exact same thing.

Yes, sometimes the C standard clashes a bit with what we would expect
the compiler to do, but that is just tough luck ;)

> There are other issues that may make this code unsafe when used outside
> of an interrupt routine. This applies to any volatile data that is
> greater than 8-bits used on an 8-bit processor.
> 
> I guess that its not enough to declare the 32-bit variable volatile. It
> needs to be wrapped in an atomic cli/sei section.

That too. Preferably using the macros in atomic.h.

> If the load sequence of 4 registers is interrupted halfway and an
> interrupt changes one of the bytes that was already loaded into a
> register, then the whole volatile concept is meaningless anyway.
> 
> Perhaps the warning should be, that if a volatile is more than 8-bits,
> and its used both in and outside of an interrupt, it should always be
> protected by a block of code that is guaranteed atomic.

I've been wanting to write special case macros to read/write 8/16/32
bits atomic variables for a long time, but never got around to do it.

With those you could actually avoid declaring the variables as volatiles
and just use the special accessor functions in appropriate places. This
way accesses inside interrupts (for instance) could be done without any
special tricks, and it would probably solve your case too.

-- 
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"For every problem there is one solution which is simple, neat, and wrong."
H. L. Mencken