Re: [avr-gcc-list] volatile...

[Paulo Marques]

Dave Hansen wrote:
> From: Paulo Marques <address@hidden>
> [...]
>> But you're actually wrong about the volatile not being needed. Because
> > the "sei" instruction doesn't claim anything about memory clobbers, 
> > without volatile the compiler would be free to re-order instructions 
> > and do the "sei" before the assignment.
>
> Ouch.  I would have thought the "volatile" int the sei macro would have 
> taken care of this.

IIRC the volatile in the asm macro only implies that it can not be 
reordered with other volatile macros, or that it can not be optimized 
away just because the compiler doesn't understand its side-effects (but 
I might be wrong here).

> > This is no theoretical scenario. Just search the archives for previous 
> > threads over this.
>
> I didn't find anything in a quick search, but I believe you.

You can check this post and the discussion that follows (about one year 
ago):

http://lists.gnu.org/archive/html/avr-libc-dev/2005-12/msg00015.html

> Would declaring the variable (ret) 'volatile' let us remove the cast?

It would, but it would also force the compiler to create a full stack 
frame to store ret alone, instead of using cpu registers. The resulting 
code is not pretty at all. Even more, this is just a consequence of you 
lying to the compiler, since it is not actually "ret" that is volatile, 
but the value you're trying to access.

BTW, I still had that code wrong. The proper way (tested, this time) 
with the correct volatile keyword placement and the flags save/restore 
code is:

static uint16_t atomic_read_16(uint16_t *ptr)
{
        uint16_t ret;
        uint8_t flags;

        flags = SREG;
        cli();
        ret = *((volatile uint16_t *)(ptr));
        SREG = flags;
        return ret;
}

--
Paulo Marques - www.grupopie.com

"The face of a child can say it all, especially the
mouth part of the face."