Re: Atomic accesses on ARM microcontrollers

[Patrick Oppenlander <patrick.oppenlander@gmail.com>]

On Sat, Oct 10, 2020 at 11:42 PM Jonathan Wakely via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> On Fri, 9 Oct 2020 at 19:29, David Brown <david.brown@hesbynett.no> wrote:
> >
> > I don't know if this can be answered here, or would be best on the
> > development mailing list.  But I'll start on the help list.
> >
> > I work primarily with microcontrollers, with 32-bit ARM Cortex-M devices
> > being the most common these days.  I've been trying out atomics in gcc,
> > and I find it badly lacking.  (I've tried C11 <stdatomic.h>, C++11
> > <atomic>, and the gcc builtins - they all generate the same results,
> > which is to be expected.)  I'm concentrating on plain loads and stores
> > at the moment, not other atomic operations.
> >
> > These microcontrollers are all single core, so memory ordering does not
> > matter.
> >
> > For 8-bit, 16-bit and 32-bit types, atomic accesses are just simple
> > loads and stores.  These are generated fine.
> >
> > But for 64-bit and above, there are library calls to a compiler-provided
> > library.  For the Cortex M4 and M7 cores (and several other Cortex M
> > cores), the "load double register" and "store double register"
> > instructions are atomic (but not suitable for use with volatile data,
> > since they are restarted if they are interrupted).  The compiler
> > generates these for normal 64-bit types, but not for atomics.
> >
> > For larger types, the situation is far, far worse.  Not only is the
> > library code inefficient on these devices (disabling and re-enabling
> > global interrupts is the optimal solution in most cases, with load/store
> > with reservation being a second option), but it is /wrong/.  The library
> > uses spin locks (AFAICS) - on a single core system, that generally means
> > deadlocking the processor.  That is worse than useless.
> >
> > Is there any way I can replace this library with my own code here, while
> > still using the language atomics?
>
> Yes. My understanding is that libatomic is designed to be replaceable
> by users who want to provide their own custom implementations of the
> API.
>
> You're using bare metal ARM, right? For Arm on Linux I think there are
> kernel helpers that make the atomics efficient even when the hardware
> doesn't support them.

Hi Jonathan,

AFAIK https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456 has not been
resolved, which means that you can end up with a weird mix of gcc
builtins and your own provided functions.

Patrick