From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from asav22.altibox.net (asav22.altibox.net [109.247.116.9]) by sourceware.org (Postfix) with ESMTPS id EE1483857C4E for ; Mon, 12 Oct 2020 07:17:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EE1483857C4E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=david.brown@hesbynett.no Received: from mail.jansenbrown.no (unknown [92.221.34.247]) by asav22.altibox.net (Postfix) with ESMTP id 0EC9320097; Mon, 12 Oct 2020 09:17:38 +0200 (CEST) Received: from [192.168.0.63] (unknown [79.161.10.130]) by mail.jansenbrown.no (Postfix) with ESMTPSA id B2A0B2012CD; Mon, 12 Oct 2020 09:17:37 +0200 (CEST) Subject: Re: Atomic accesses on ARM microcontrollers To: David Brown , Jonathan Wakely Cc: gcc-help References: <945d5e74-b449-3746-6560-996d0437db76@hesbynett.no> <6cfc20a9-05c5-e2be-d9f0-d10911268b4a@hesbynett.no> From: David Brown Message-ID: <3322a4de-263c-7c07-c2d7-47e7274d5f56@hesbynett.no> Date: Mon, 12 Oct 2020 09:17:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <6cfc20a9-05c5-e2be-d9f0-d10911268b4a@hesbynett.no> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=Du94Bl3+ c=1 sm=1 tr=0 a=+Fy6h7hJ4UJcWgHwdIx3jg==:117 a=+Fy6h7hJ4UJcWgHwdIx3jg==:17 a=IkcTkHD0fZMA:10 a=afefHYAZSVUA:10 a=PeOOapuUAAAA:8 a=fzj6zdruG4d3Qjr1j34A:9 a=QEXdDO2ut3YA:10 a=0BaqRfgCL6CLbWgV2pdm:22 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=no 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 07:17:42 -0000 On 10/10/2020 21:43, David Brown wrote: > > If I understand you correctly, you mean that I can simply implement my > own version of __atomic_load_8 and other functions in libatomic? > > I had a quick test (using the godbolt.org online compiler). > > By adding this to my file: > > extern inline > uint64_t __atomic_load_8(const volatile void * p, int order) { > (void) order; > const volatile uint64_t * q = (const volatile uint64_t *) p; > return *q; > } > > then a straight load of a 64-bit atomic becomes a single "ldrd" load > double register instruction, which is optimal for this processor. (In a > finished solution, I'd want to check that this is correct for different > flags - possibly adding function attributes for optimisation or inline > assembly to ensure that it is always correct. But that's a detail for > me to check.) > > The same worked for __atomic_store_8. > Just to be clear here, in case anyone else is reading these posts and uses them for their own code, a single "strd" store double register operation is not, in general, strong enough for the __atomic_store_8 on the Cortex-M devices. If the processor gets an interrupt while executing the strd, it may have stored the first half of the new value but not the second half. If the interrupting code then reads the object, it will get an inconsistent read. (If that can't occur - maybe only your interrupt routine changes the object - there's no problem.) So the __atomic_store_8 should disable interrupts around the write. (And again to be clear, this is for single-core microcontrollers with bare metal, rather than for multi-core or with a host host.) > (The general load/store functions are a bit more involved, as are the > read-modify-write atomic functions.) >