From nobody Sun May 30 06:04:39 2021 X-Original-To: freebsd-ppc@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4363CD7FF22 for ; Sun, 30 May 2021 06:04:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ft7Dc2JnWz3lhg for ; Sun, 30 May 2021 06:04:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622354686; bh=EdbnXb7kCK9FLTuqYRrbwGDq0UweQKcAnLStWk9/0Nw=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=G2btl9YACXkv7/FxQU+h5L1Ohs0irW2NiddtEvw4h5gbOk3UJz5UAVodn3RMinWqh2LOcwjgEPx4tCEAUI7tCfCKk7crfLYaX9vQ3S48ecGURiB6A7HCEe+Vq9LsLZVKXd1ncBcEn5pT3P8OamC8Wjq/fct3xR3p5fi1daz5Wt8HxZqz0711calg2bnX3GdDO6Q74UXaKtt7IL0PISyk8jqv/DYomNdpq3cPehzdF+Q0rEFiuQQr6XBG4vNuJQPNnFQNRgwlZbrX7OexSC9txTGWqkO7KQVqee4U0lkiYcCWLN1gatQ2qX+0QB/cqzWlCrWBOMLJ3Dszex+7cLwm4A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622354686; bh=5GxRGIrno1TAU1JaFa+VDo/QdoEek5Qb6qqBXbJVEN0=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=rNVT8grJHnTYSsGwWSCmWAZ04zEOzFGX3ztJmKkKlNOXlQtOg+GwaQIvu/Fz5W74s9ovGmpUy0iWLQ/fAIo9VB4qVVH8moY+Qq4WtC0ilTRDHsen85XBXzjI4CZdigzPsecaUTVe9EyGY/+znc9DXnu9tMDLE9XWRnl4r0M5j5G2NbT3U7jK07OT1Xb+IkWVerb3sAr2Ye8SKxOngr1a131VA3wxn7cns8YltYX3jaUWAblTKvR2sbmV/4TIgRePpzi+a8mgFVJBcyO6vjC43zkHo0f/FjywOmkH9dVbmXtDUPfSNOkm8bCA1FR21Svizk7HrxyV2S01est03e5PTg== X-YMail-OSG: T1qf7NYVM1m5jkXdYovcpJWSpYIqBDsGPoNitP0DCBInPXX2e7KXBmR5uYVGi7N g3qILq452RkHwUaKWB.12DBfs_v57cj.P1FCwHrgGiiNxpwaPibUOVTRKWll_0D1e8YUUGDg_4ok MFWSGBEize5n9H2KHUduKjFOfAmh5Horh8PoJHHsVtO2skOZMVwEStgW429_j5yuAjed67bUCZEc RNzw1EWPlDedBO8QO_BiTroVQ.HcWzBhfFjsK2tm81HwXRksflwvAresvvaCl8J7lCKOGkKAQcTf 9sNT8PQFRUs1bRMoqvQDcDj.YMYRhwktuoS7_f38DRA3mVVfoERqdGdSsojX8OKgFeI.jbu9ncmw f74HrMccJ9zkIekk_2Tt9cXKJvZn8__znW6tEV6mn5gC9zF2G.7AS4K8d_DdKo3lnss8J2t6.NtC m6GiC.eZjqpgye42eCTxdCvpwX9dfTdo4Gx5PtMzo8R7UK.i5RQy1aDVXUDNG0MEGZBHHbjFWm3I 6NtV9_A5PpED5PKlDf3s76oQ8iNQrvmwHZGnVZPIKgcV6Z2AVHGFl0Ob0C1kFsUpydy0TjyAVjxI 0GFIGOpXaZpRY7uktk2Sb3LxJitmPfUMcC7gc1ttH3xrcpm9_Q36Cj_goQ3_UrUyjgpUcfNazH_6 gGpXUsAagEyl0WXYzT8hj9wKsdXkCScSoTUC124k4vOh9R9c7286tvkuJkn2BWhJkAC_m6ZbadT1 6ow0GABUeG2V6SHC03hk7V5QlO5EdaPtxgQtAfWetExzL2lEd8533YJb7PX4hhWOsONDW0BVHYYu F6b4VJBGoh3NZqzE4jbAMZZYeF8hRdRW4vLdXbkk2oNmyW9QapEZquymq_Qw_fG4GABiEmMrOfEE zmFZrlAxE4r3zSqd9yXT3ce40Qpy08CxaYYgDTbJumbql5XXZb6YTfjIGO9nrxPKCHVwq_43gNga Sl4mD2ppAS4_KxO_YXaa4aS8Fwp0ilYeflURFk2BzbBpXJ01koFkeWRsne.FOqxEnwfx9vlT5Nh1 RbO_J0qwwTE.tvOn.oWML3lEnokXBFR4i0deNMqrR0xG5ddXX_Ypo9iUpkmywcK09mAOwphfyxZE JpnqwwqU7ZTgMXpkTyshiS.YN9ByhWMSafJB8RoKHDjuhgQECxtCq7LZbNb0fT1drOQJyIj4xJnD Q_IZ_9.OXrEbSjQ1hD2EzmCrQBy_wWnIa3hTxflXMsUc.dSB3i.AKE1vyMDFQw8hUl1A9OINJVt_ ssDNBcg7PqfuviwSqk6ZH2MB5OvZ34XCHNgZ_II.lzmJADdUHDJq4vbbcbdL3kDRkmYOB1ozMhdT W02JGnKVyqCYEPZGNUSHCofy3HALbL7aSb7Jx3G.SZ8m6u.ltBdMlRbGgyXkve3RoIxMPqC9OF9R 9MIzER8JK_YFr9CdMBmN9BpkUko0BfujywxouxaeWRp9ZO8tRyBb6N1sZyD6XNM_0tSk5IGK0dpq Re6bEq_Mlq57sZf8AyE.p_ndAqR18VL.csoSIZd2zEXLVpBwoQIlOY05ULax36hVMJIcvK6_alnN pB_7PyAMsluMN4.VNUTIpmyVsygVZnCt_iHm5bmUsZdYnoT88RtKyCR5WV0XL5qJkg0SMRwWbf.b qE2vTMJFvEwgO3HA_.viDz_DVhK42S.OlT8.CPB3qo5BdipEjgecdUD9zdnjyIl.HXh8FL7XVOSA XFoRoolWEIMnRNC6.HaS3vEw._uFI9Kc3OafIbJfyG1hdgIJb5BsRdA8kVa_7ZvzLTakvHtdKddm f.1A84LFqlc7QKgvGbJ8OfDDiMYtNT_zDB8EyJRUghpYRivs880Qyfm3RbqxBHQXp51pb_iHdly9 iDqL4md7fbxhA4QK.l3hU7v3UmOJRhtOlQUTJXv0aa12ZBBme6WbdLvi86E4EjdR5fzmxxWJYgvQ p7ieby6rRqF7lhksIFQDHXwOnSWokF3t2ukPJWhOlKmEuPHr2gvdmwkTV3.jVMhYgsCjO88pXc._ 1DjccgJxBU6D9Hl1FRII1nVzPIz2yju032nK0wJEvDkx_zFsHeGVBTRn7XA5sdvOrAvmGuzWg.xO iOBC2kZ1X2cjCjCb3jq31EH6cJDQSLgEM46howfNFNmIg_8kKsZknedm1njqUwfP.4jrBcCzTfWL 9R9S1U794EZJOk6sq8T1JS.Eh5ITqnJx_cM6wyy_hRp08Stlpz0_weSy5dchqhgTGWzgjyB6sP64 KTyHauIiWLH5glhFuVMR.0HFlwolRySrMPzExnCH_yGH_Q4tiuZrWYG22BLvKuHtLuPF1wuIeAdN KvmIiHfaasMYvirRBhsr6GBFHgAa56pvZStggB0RA3vwoOUzh2GhA9oQsf9gdZmzyxLWfs7xpbt8 REtjAb1hLR_ID8lNL1sMbh5OZkLmpBzfAv9bS3ovqpfcKFmPUJmf6y2yn6w_tCgfzacAz93zridq hmBqKIGXfLOup_LoedcBT5eNTz63F8KE0WbFIVDiIvQyrjLdC18WiY03N6tTRepREIfBJDDi6vmP 4U_uGzvjmhqPGFBx4gibribJJTvblE1iV6NOBsscNb8mOJVV.Nv7tcZvyow4DGjW5WGdO2VpnHMr KbDjkCruNa_wrW1oqBg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 May 2021 06:04:46 +0000 Received: by kubenode546.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 98f4ca3372e954155aa7f1473c8a2396; Sun, 30 May 2021 06:04:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Porting FreeBSD to the PowerPC List-Archive: https://lists.freebsd.org/archives/freebsd-ppc List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Is powerpc64 atomic_load_acq_##TYPE omitting isync believed correct? Message-Id: <07D39D7F-711B-4FF3-AA33-AB691C231FA4@yahoo.com> Date: Sat, 29 May 2021 23:04:39 -0700 Cc: FreeBSD Hackers To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3654.80.0.2.43) References: <07D39D7F-711B-4FF3-AA33-AB691C231FA4.ref@yahoo.com> X-Rspamd-Queue-Id: 4Ft7Dc2JnWz3lhg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=G2btl9YA; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.66.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.66.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-hackers X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N In the code from /usr/include/machine/atomic.h for powerpc64 and powerpc there is: #define ATOMIC_STORE_LOAD(TYPE) \ static __inline u_##TYPE \ atomic_load_acq_##TYPE(volatile u_##TYPE *p) \ { \ u_##TYPE v; \ \ v = *p; \ powerpc_lwsync(); \ return (v); \ } \ \ static __inline void \ atomic_store_rel_##TYPE(volatile u_##TYPE *p, u_##TYPE v) \ { \ \ powerpc_lwsync(); \ *p = v; \ } This code sequence does not involve isync: #define __ATOMIC_ACQ() __asm __volatile("isync" : : : "memory") What justifies this? All the reference material I've found for C++/C11 semantics agrees with: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html that shows (organized here to compare Relaxed vs. Acquire and Release): powerpc Load Relaxed vs. Acquire: ld vs. ld;cmp;bc;isync powerpc Fence: Acquire: lwsync powerpc Store Relaxed vs. Release: st vs. "Fence: Release";st powerpc Fence: Release: lwsync lwsync does not order prior stores vs. later loads, isync does (and more in some respects). That likely (partially) explains why load-acquire does not use just an acquire-fence in such materials. Is this a problem for being correct for "synchronizes with" in "man atomic"? For the acquire operation reading the value written by the release operation: QUOTE . . . the effects of all prior stores by the releasing thread must become visible to subsequent loads by the acquiring thread END QUOTE It seems that some later loads could be moved by the hardware to be too early relative to various such prior stores (as seen in the load-acquire thread): no constraint is placed for such relationships by the atomic_load_acq_##TYPE as far as I can see. (I got into this by finding some code that uses an atomic_store_rel_##TYPE without any matching use of atomic_load_acq_##TYPE or atomic_thread_fence_acq or other such, so far as I found. But, looking around to see if I could find a justification for such code, generated more questions, such as in this note.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)