Re: asm volatile statement reordering

[Sebastian Huber <sebastian dot huber at embedded-brains dot de>]

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@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.