public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: gcc-help@gcc.gnu.org
Subject: Atomic accesses on ARM microcontrollers
Date: Fri, 9 Oct 2020 20:28:05 +0200	[thread overview]
Message-ID: <945d5e74-b449-3746-6560-996d0437db76@hesbynett.no> (raw)

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?

David




             reply	other threads:[~2020-10-09 18:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 18:28 David Brown [this message]
2020-10-09 23:28 ` Segher Boessenkool
2020-10-10 12:39 ` Jonathan Wakely
2020-10-10 19:43   ` David Brown
2020-10-10 20:18     ` Jonathan Wakely
2020-10-11 10:54       ` David Brown
2020-10-12  7:17     ` David Brown
2020-10-12 21:44   ` Patrick Oppenlander
     [not found] ` <b29b1595-9441-68eb-f257-244a35082c82@winterflaw.net>
2020-10-10 19:43   ` David Brown
2020-10-10 20:09     ` Jonathan Wakely
     [not found]     ` <bdf0f96f-0377-bee7-c02e-9704f0bea6a5@winterflaw.net>
2020-10-11 12:16       ` David Brown
     [not found]         ` <24c49c76-43c3-9a0d-6b02-a4340b1fccba@winterflaw.net>
2020-10-11 12:51           ` David Brown
2020-10-13 11:46             ` Richard Earnshaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=945d5e74-b449-3746-6560-996d0437db76@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).