Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR toolchain/54431; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms
Date: Sat, 3 Aug 2019 03:46:10 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --I4ptJEDr2abzWe6gQns0M4eqtNszrE1Y5
 Content-Type: multipart/mixed; boundary="nCr0hHIhWCUhGTUoQz54UCM092GVXeHbN";
  protected-headers="v1"
 From: Kamil Rytarowski <n54%gmx.com@localhost>
 To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%NetBSD.org@localhost>
 Message-ID: <6d527e62-6019-2171-e043-92b0c0a3aa45%gmx.com@localhost>
 Subject: Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms
 References: <pr-toolchain-54431%gnats.netbsd.org@localhost>
  <20190802113117.9AB1F43F4E9%smistad.uninett.no@localhost>
  <20190802134001.AE80D7A1C0%mollari.NetBSD.org@localhost>
  <20190803004430.GB23485%bec.de@localhost>
 In-Reply-To: <20190803004430.GB23485%bec.de@localhost>
 
 --nCr0hHIhWCUhGTUoQz54UCM092GVXeHbN
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable
 
 On 03.08.2019 02:44, Joerg Sonnenberger wrote:
 > On Fri, Aug 02, 2019 at 01:40:01PM +0000, Kamil Rytarowski wrote:
 >>  We already ship with ras(9) that is significantly worse and does not
 >>  work in probably any SMP or shared memory scenarios.. but we ship wit=
 h
 >>  it basically in every port as in UP setups it can be good enough.
 >=20
 > ras(9) is nearly zero overhead and *only* meant to help implementing
 > atomics on UP architectures. It doesn't care about shared memory at all=
 =2E
 >=20
 
 ras(9) having nearly 0 overhead is debatable as it is used in every
 cpu_switchto(9) call, even if there are nearly no users of it on modern
 CPUs.
 
 Similar with libatomic, users of it do not care about shared memory
 unless they are doing something wrongly. No need to push the bar too
 high that cannot be solved (without switching to UP kernel mode)
 
 I see no problem with performance hit. It can be really slow, but
 running existing unmodified code is a good tradeoff.
 
 >>  libatomic in general works unless we are in fewer corner-cases.
 >=20
 > I do not call shared memory a corner case. Given that one of the reason=
 s
 > that certain folks are loudly pushing for futex semantics everywhere is=
 
 > because they want to implement locking primitives in shared memory, tha=
 t
 > shouldn't be surprising at all. Given that double width cas is the
 > typical solution for dealing with lock-free data structures, even less.=
 
 >=20
 
 With the switch from libatomic_ops to C11/C++14 atomics there will be a
 growing demand for a fallback library implementation (unless we will
 stop caring about hardware predating 64/128bit atomic operations).
 
 One of the candidates for libatomic in base is LLDB (I am aware that we
 can patch LLDB to stop demanding it).
 
 >>  SPARC implementation could be improved if needed and should not block=
 
 >>  ppc or i386.
 >=20
 > I meanted Sparc because it is the one architecture with a non-trivial
 > deployment of SMP systems and without native CAS or LL/SC. I don't coun=
 t
 > VAX. That said, the problems of Sparc atomics is shared with 64bit
 > atomics on 32bit PPC and i386 as well as 128bit atomics on most LP64
 > platforms.
 >=20
 
 With the push toward at least CHERI 128bit pointer architecture, we are
 going to have a growing need for 128bit atomics.
 
 They are already in toolchains and allocators.
 
 > Joerg
 >=20
 
 
 
 --nCr0hHIhWCUhGTUoQz54UCM092GVXeHbN--
 
 --I4ptJEDr2abzWe6gQns0M4eqtNszrE1Y5
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAEBCAAdFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAl1E52IACgkQS7MI6bAu
 dmxYXBAAlH7A3YCOvgG8zaJEW2o4UXzlG2w6wlZUhfonMbWTt8tukOGZ1naX3WVE
 UbUu/kLrbzwQ3YQKZe4HrZAfgq3fqrxvdOrRAABSEpc7PSAQeFyvxD8oDLbEiT0P
 qwGu6zRBvRY6TGMgk6D/2LpbGoSqZGETSaf4sXUt5frAs3CtbyLVk/C7WHIVkP9u
 YqV2pSBibemQL8QGIexymvGCN0ZDHfI3zAiXeVaMd8+RlCg9w0YOE8vvCE59tVWU
 Grl7Bx06iIxrtvOHCmk8RcsAlADGDA5+o7wSQ8RouIBFUrsXW7/RTDNNIK3Z8yuQ
 4Ri7rXeOG+5jSl5mtr6Y5RBbBYxtI6cDc0rQnOd3/NPPFrdaGegCIE0Jf0Pc0IFn
 2cw1g+OS7Z4Q47b3hg36NrMueHt0q+Yj5t3pzWe083hMjSK6OYIgF+j4FESKVjUS
 tXlfjnHCIsI0WmDiB4h8Ucqd3gABGD/Sp+qpIo8uxRDGQakgwsv+c0IadYwhnsiA
 EP80lzZcm4iIB8StNDT3sRs3mXk2PtUhhfQbHIEN26ZXHbEfyw9H2AH07tuLlqsG
 kI233bJwntB9ZJCK0D2zgKEjPZfUd6ZA5UJ9eN7fpB4E/8PZctAyspINTPkClSHQ
 uf88bQMiLRTvsIs9ZESEMbW17jBMOTdLcUco8OLOs0reHWhjM6A=
 =h+EU
 -----END PGP SIGNATURE-----
 
 --I4ptJEDr2abzWe6gQns0M4eqtNszrE1Y5--