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
