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
Cc: 
Subject: Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms
Date: Fri, 2 Aug 2019 15:39:13 +0200

 On 02.08.2019 14:30, Joerg Sonnenberger wrote:
 > The following reply was made to PR toolchain/54431; it has been noted by=
  GNATS.
 >
 > From: Joerg Sonnenberger <joerg%bec.de@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: toolchain/54431: Missing 64-bit atomics on 32-bit platforms
 > Date: Fri, 2 Aug 2019 14:27:41 +0200
 >
 >  On Fri, Aug 02, 2019 at 11:35:00AM +0000, he%NetBSD.org@localhost wrote:
 >  > 	It appears that at least our powerpc and i386 ports do not
 >  > 	support any sort of 64-bit atomic operations.
 >
 >  I do not consider this a bug. The reality is that there is no good way
 >  to provide fall back implementations for larger-than-pointer atomics on
 >  most UP platforms or atomic emulation in general on MP platforms.
 >  We have some hacks on SPARC using hashed locks, but they have major
 >  subtile error cases. Most noticable, they don't work on shared memory.
 >  There is a secondary issue for larger-than-pointer atomics because most
 >  architectures don't have atomic read or write instructions for that
 >  size. At least for the old __sync_* interface that is a major deal
 >  breaker as the load/store is typically written as fence + plain C
 >  volatile load/store.
 >
 >  Any correct implementation will involve a system and hashing of the
 >  physical address of the access memory for larger-than-pointer access fo=
 r
 >  any operation. I'm pretty sure that is going to kill the performance of
 >  a lot of those users. It doesn't help that there is no way for the user
 >  to promise that a certain memory address is not shared...
 >
 >  Joerg
 >
 >
 
 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 with
 it basically in every port as in UP setups it can be good enough.
 
 libatomic in general works unless we are in fewer corner-cases.
 
 SPARC implementation could be improved if needed and should not block
 ppc or i386.
 
 More modern i386 (>=3D 586) supports 64bit atomics natively with cmpxchg8b=
 .