On 28/02/14 13:19, Richard Sandiford wrote:
> Georg-Johann Lay <a...@gjlay.de> writes:
>> Notice that in code1, func might contain such asm-pairs to implement
>> atomic operations, but moving costly_func across func does *not*
>> affect the interrupt respond times in such a disastrous way.
>>
>> Thus you must be *very* careful w.r.t. optimizing against asm volatile
>> + memory clobber. It's too easy to miss some side effects of *real*
>> code.
>
> I understand the example, but I don't think volatile asms guarantee
> what you want here.
>
>> Optimizing code to scrap and pointing to some GCC internal reasoning or some
>> standard's wording does not help with real code.
>
> But how else can a compiler work? It doesn't just regurgitate canned code,
> so it can't rely on human intuition as to what "makes sense". We have to
> have specific rules and guarantees and say that anything outside those
> rules and guarantees is undefined.
>
> It sounds like you want an asm with an extra-strong ordering guarantee.
> I think that would need to be an extension, since it would need to consider
> cases where the asm is used in a function. (Shades of carries_dependence
> or whatever in the huge atomic thread.) I think anything where:
>
> void foo (void) { X; }
> void bar (void) { Y1; foo (); Y2; }
>
> has different semantics from:
>
> void bar (void) { Y1; X; Y2; }
>
> is very dangerous. And assuming that any function call could enable
> or disable interrupts, and therefore that nothing can be moved across
> a non-const function call, would limit things a bit too much.
>
> Thanks,
> Richard
>
>
I think the problem stems from "volatile" being a barrier to /data flow/
changes, but what is needed in this case is a barrier to /control flow/
changes. To my knowledge, C does not provide any way of doing this, nor
are there existing gcc extensions to guarantee the ordering. But it
certainly is the case that control flow ordering like this is important
- it can be critical in embedded systems (such as in the example here by
Georg-Johann), but it can also be important for non-embedded systems
(such as to minimise the time spend while holding a lock).
David
