avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dale Whitfield
Subject: Re: [avr-gcc-list] Re: Optimisation of bit set/clear in uint32_t
Date: Wed, 22 Apr 2009 14:09:39 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Graham                                        >@2009.04.22_13:55:50_+0200

> Dale Whitfield wrote:
>
>> Its how volatile works by *loading* the registers before making changes.
>> However, if its possible to only store back changed bytes, then surely
>> that's all that needs to be done.
>
> Your understanding of volatile is not correct.  By saying ...
>

This is my point exactly. What does volatile mean?

>> :-) I guess we need to agree to disagree on this.
>
> ... you are declining to be corrected.  Enough said (I hope).
>

Not at all. I accept the opinions because volatile is poorly defined to
start with. 

What you understand is correct may not be what I understand to be
correct. Its not a cut and dried issue.

You can search for the Linux Kernel debate on this back as far as 2006
where Linus said somewhere:

<quote>
The fact is, "volatile" simply doesn't inform the compiler enough about
what the effect of an access could be under various different situations.

So the compiler really has no choice. It has to balance the fact that the
standard requires it to do _something_ different, with the fact that
there's really not a lot of information that the user gave, apart from the
one bit of "it's volatile".

So the compiler really has no choice.

Btw, I think that the whole standard definition of "volatile" is pretty
weak and useless. 
<endquote>

With which I whole-heartedly agree.

> Graham.
>
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]