On 17/10/17 12:20, David Brown wrote:
I am trying to establish exactly what gcc does, and what guarantees it
may or may not give. Based on that, I can see if current solutions in
source code are strong enough, or if they need workarounds, and if I
should be filing an enhancement request.
I disagree. If you want a bunch of asms to execute in a particular
order, add a memory clobber or some dependencies. It's not difficult
once you have the understanding. In this particular case, fixing it
is trivial, and there are many ways to do it.
I understand about dependencies. (I also know about memory clobbers,
but these tend to be a fairly blunt instrument and can lead to wasted
cpu cycles, especially on RISC cpus with lots of registers. When you
are dealing with things like critical sections with interrupts disabled,
you are often trying to minimise the cycle time.) My solution to this
particular ordering problem is:
I performed a simple test on x86_64. With -O GCC kept "status" in
register. The clobber just tells GCC there is a dependency and won't
slow down the program.
The cost of memory clobbers only appears when you have data that could
have been kept in registers, but is forced out (with extra loads and/or
extra stores) due to the clobber. You don't see it on simple tests, and
you get it much more often on devices with more registers.
Would something similar to the thread fence semantics (acquire, release,
etc.) of the C11/C++11 atomics for inline asm statements help?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber@xxxxxxxxxxxxxxxxxx
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
