On Sat, Oct 10, 2020 at 11:42 PM Jonathan Wakely via Gcc-help <gcc-help@xxxxxxxxxxx> wrote: > > On Fri, 9 Oct 2020 at 19:29, David Brown <david.brown@xxxxxxxxxxxx> 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
