[Top][All Lists]

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

Re: [avr-libc-dev] Re: bug #22163 (atomic not working as expected inC++)

From: David Brown
Subject: Re: [avr-libc-dev] Re: bug #22163 (atomic not working as expected inC++)
Date: Thu, 10 Jun 2010 10:46:15 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

On 09/06/2010 22:52, Joerg Wunsch wrote:
As David Brown wrote:

Eric suggested making "some_temp_variable" volatile, which is the
traditional way to enforce ordering in C programming.  Strictly
speaking, you don't have to make it volatile - it's enough to make
sure it is in memory if cli() and sei() have memory blocks.

Yes, but again: forcing the variable into memory is a pessimization.
It's not required for the job, but something like that is currently
the only way to force the compiler into doing what the programmer

Pretending to use the variable in an assembly statement should also work, with no extra code generated. The syntax is slightly ugly, but it could be wrapped in a macro:

#define forceGenerate(x) asm volatile("" :: "r" (x))

I can't think of any way to automate this with changes to the cli() macro, but that's not surprising as the C language doesn't have the relevant concepts.

If you have a code snippet that shows this sort of re-ordering, it would be nice to try it with the above macro and see if it fixes the problem.

(suggested language extension)

I'm not sure there is any way to give a solid definition of the
semantics of "volatile" here.  And I suspect that you'll have
/slightly/ more difficulty getting this into mainline gcc than for
other extensions such as 0b binary constants...

Yeah, sure.  No, this won't be me to implement it...

reply via email to

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