|
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:1.9.1.9) 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 intended.
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...
[Prev in Thread] | Current Thread | [Next in Thread] |