svn commit: r353296 - head/sys/powerpc/include

[Justin Hibbits]

On Tue, 8 Oct 2019 11:16:04 +0300
Konstantin Belousov <kostikbel at gmail.com> wrote:

> On Tue, Oct 08, 2019 at 01:36:34AM +0000, Justin Hibbits wrote:
> > Author: jhibbits
> > Date: Tue Oct  8 01:36:34 2019
> > New Revision: 353296
> > URL: https://svnweb.freebsd.org/changeset/base/353296
> > 
> > Log:
> >   powerpc: Implement atomic_(f)cmpset_ for short and char
> >   |
> >   This adds two implementations for each atomic_fcmpset_ and
> > atomic_cmpset_ short and char functions, selectable at compile time
> > for the target architecture.  By default, it uses a generic
> > shift-and-mask to perform atomic updates to sub-components of
> > 32-bit words from <sys/_atomic_subword.h>. However, if
> > ISA_206_ATOMICS is defined it uses the ll/sc instructions for
> > halfword and bytes, introduced in PowerISA 2.06.  These
> > instructions are supported by all IBM processors from POWER7 on, as
> > well as the Freescale/NXP e6500 core.  Although the e5500 and
> > e500mc both implement PowerISA 2.06 they do not implement these
> > instructions. As part of this, clean up the atomic_(f)cmpset_acq
> > and _rel wrappers, by using macros to reduce code duplication.
> >   
> >   ISA_206_ATOMICS requires clang or newer binutils (2.20 or later).
> >  
> Why don't you use normal word-sized ll/sc tlwarx/stwcx, and only
> modifying the part of the register as needed ?  This would work on
> all supported CPUs, right ?
> 
> When kevans did the _atomic_subword.h, one of the arches involved was
> sparc64, which does not have ll/sc.  Also for MIPS there are some fine
> details which might mean that C implementation is less work than using
> word-sized ll/sc.  But why for power ?

No real significant reason.  In fact, the review's diff has exactly
what you're asking for.  The only reason I modified it for commit with
Kyle's work was purely readability, I thought using the C wrapper with
atomic_fcmpset_() was just marginally cleaner. I haven't checked, but I
don't think the inline code difference is too great, but I'll have to do
another review of it to be sure.  It's easy enough to commit the
original diff over top instead, if that's the better way to go.

- Justin