Hi Alex,
On Wed, Apr 22, 2009 at 5:51 AM, Alex Wenger wrote:
...snip...
>>> Try the following version of set_status:
>>>
>>> void set_status(uint32_t flag, uint8_t set) {
>>> if (set) *(uint32_t* &status) |= flag;
>>> else *(uint32_t* &status) &= ~flag;
>>> asm("" : : : "memory");
Dale Whitfield wrote:
> 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
Hi David >@2009.04.22_12:48:52_+0200
> However, based on your other post in this thread, you are correct in
> that volatile access is not what you need - it's atomic access (that
> applies to 8-bit data as well as 32-bit data).
>
I need to make it ver
Dale Whitfield wrote:
... volatile is poorly defined to start with.
This just isn't true. Volatile is as well defined as most other advanced
features of the language. The problem is that it is poorly understood and
unevenly implemented.
I know what Linus said about volatile and this stat
Hi,
> There is every reason. The flags get updated in interrupt routines and
> in non-interrupt code.
>
>> Try the following version of set_status:
>>
>> void set_status(uint32_t flag, uint8_t set) {
>> if (set) *(uint32_t* &status) |= flag;
>> else *(uint32_t* &status) &= ~flag;
>>
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,
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
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 ...
:-) I guess we need to agree t
Hi,
> Reads or writes, I believe, can be removed when updating a volatile that
> is greater than 8-bits.
an example is a 16-bit timer counter register, where writing the hi-byte
triggers the uptdate of the timer.
-Alex
___
AVR-GCC-list mailing list
Hi Alex >@2009.04.22_09:51:59_+0200
> Hi,
>
> >>> That's way too much code... Its fairly obvious where the optimisations
> >>> should be, although I can see that some have been done already.
> >>>
> >> I can't see much possibility for improving the above c
Hi David >@2009.04.22_10:55:27_+0200
> Dale Whitfield wrote:
>> Hi David >@2009.04.21_19:42:34_+0200
>>
>>> Dale Whitfield wrote:
Hi,
All this talk of super-optimisers, etc. brings this issue I've had,
>
Hi,
>>> That's way too much code... Its fairly obvious where the optimisations
>>> should be, although I can see that some have been done already.
>>>
>> I can't see much possibility for improving the above code (except by
>> removing the push and zeroing of r1). You asked for "status" to be a
Hi David >@2009.04.21_19:42:34_+0200
> Dale Whitfield wrote:
>> Hi,
>>
>> All this talk of super-optimisers, etc. brings this issue I've had,
>> to the fore again.
>>
>> Perhaps there are suggestions on how to encourage the compiler to do the
>> optimisation
13 matches
Mail list logo
