From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by sourceware.org (Postfix) with ESMTPS id 1D7C63857C44 for ; Mon, 12 Oct 2020 21:45:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1D7C63857C44 Received: by mail-ed1-x542.google.com with SMTP id dg9so16298520edb.12 for ; Mon, 12 Oct 2020 14:45:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mot8gbpv40kGhG6C13w1aQAFRTLgFeh+M+YdaazTsLY=; b=NJDc8EK3yI+duzoqRe5yrO0dM4rldJW5WxhhBj5yAEWsgewk3OmSWm4Vy6TU9kXDSH NvxPRVRaXN0D0bHnVk3yT/24R0AXsnUOQwzsk2r72DS3wy8B699RS0PV1ofY8vvHGClR rW1MDtwqbFZtfQ6Veo6Ytp4QwfUeah7DQ0yWizgj1rSp+ckeeldiE0QdZS4ZdmOm2c0f i566Yqci/DvFwdigJnrwKcEFnAonv0Bqzs6690LWcZRxnDxNIeIDXPOVZuSWeXc7rfa4 lGu6WHVeqdWd/oa/4FIbT7dI5VyQKpyKeuvSXc1eG6lPCD8TSAejSfoDeARYHmbG/4E9 AjvQ== X-Gm-Message-State: AOAM533DMIhaDdcIiPtv5Ickobnv1VK0mcJTidJI3iSkIP4PiC8OqBKd t+5bimOaZbsBmiXDw8d5u7bfWYZxK7E8Sf84ajk= X-Google-Smtp-Source: ABdhPJwGBuyTsenxBfHd/ZEz9FMc2DYXH+B7Dd34AoIsoqEsq8xpB4q31RiMHXNZcKyxIUE3PTpaDdIIHkKK/bt0YYU= X-Received: by 2002:aa7:c2ca:: with SMTP id m10mr544346edp.255.1602539103129; Mon, 12 Oct 2020 14:45:03 -0700 (PDT) MIME-Version: 1.0 References: <945d5e74-b449-3746-6560-996d0437db76@hesbynett.no> In-Reply-To: From: Patrick Oppenlander Date: Tue, 13 Oct 2020 08:44:52 +1100 Message-ID: Subject: Re: Atomic accesses on ARM microcontrollers To: Jonathan Wakely Cc: David Brown , gcc-help Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 21:45:06 -0000 On Sat, Oct 10, 2020 at 11:42 PM Jonathan Wakely via Gcc-help wrote: > > On Fri, 9 Oct 2020 at 19:29, David Brown 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 , C++11 > > , 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