Some years ago I asked if ARM has sth. DCAS-like. I recently had
the idea to test for that on godbolt. With g++ unfortunately I
get a call to __atomic_compare_exchange_16 and I didn't manage
to find the sourcecode for that. But with clang++ i get the
explicit instructions: https://godbolt.org/z/PP1f8xran
Sure there's less need for a DCAS on ARM due to LL/SC, but
there are apllications where a DCAS is necessary.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Some years ago I asked if ARM has sth. DCAS-like. I recently had
>the idea to test for that on godbolt. With g++ unfortunately I
>get a call to __atomic_compare_exchange_16 and I didn't manage
>to find the sourcecode for that. But with clang++ i get the
>explicit instructions: https://godbolt.org/z/PP1f8xran
>Sure there's less need for a DCAS on ARM due to LL/SC, but
>there are apllications where a DCAS is necessary.

ARMv8.1 added a feature called Large Systems Extension (LSE)
that includes various flavors of compare and swap (8, 16, 32, 64 and 128-bit)
as well as some number of atomic load/store instructions, including
addition, bit set, bit clear, min and max.

ARMv8.0 Load Exclusive/Store Exclusive, like LL/SC doesn't scale well and should
be avoided.

On 2023-10-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Some years ago I asked if ARM has sth. DCAS-like. I recently had
> the idea to test for that on godbolt. With g++ unfortunately I
> get a call to __atomic_compare_exchange_16 and I didn't manage
> to find the sourcecode for that. But with clang++ i get the
> explicit instructions: https://godbolt.org/z/PP1f8xran
> Sure there's less need for a DCAS on ARM due to LL/SC, but
> there are apllications where a DCAS is necessary.
ARM v8.1 and later have DCAS:
https://developer.arm.com/documentation/dui0801/g/A64-Data-Transfer-Instructions/CASPA--CASPAL--CASP--CASPL--CASPAL--CASP--CASPL

--

7-77-777, Evil Sinner!
https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/

Am 25.10.2023 um 19:09 schrieb Scott Lurndal:

> ARMv8.0 Load Exclusive/Store Exclusive, like LL/SC doesn't scale well and should
> be avoided.

Maybe it would be nice to have sth. like LL/SC with multiple stores
to the same cacheline that are buffered until the last store and the
whole thing fails if the cacheline has been modified or an interrupt
has happened. I've currently no idea for an actual algorithm using
a transaction on a whole cacheline but there may be some new kind
of lock-free programming with that.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 25.10.2023 um 19:09 schrieb Scott Lurndal:
>
>> ARMv8.0 Load Exclusive/Store Exclusive, like LL/SC doesn't scale well and should
>> be avoided.
>
>Maybe it would be nice to have sth. like LL/SC with multiple stores
>to the same cacheline that are buffered until the last store and the

See

https://developer.arm.com/documentation/102873/latest/The-Arm-Transactional-Memory-Extension

On 10/25/2023 9:50 AM, Bonita Montero wrote:
> Some years ago I asked if ARM has sth. DCAS-like. I recently had
> the  idea to test for that on godbolt. With g++ unfortunately I
> get a call to __atomic_compare_exchange_16 and I didn't manage
> to find the sourcecode for that. But with clang++ i get the
> explicit instructions: https://godbolt.org/z/PP1f8xran
> Sure there's less need for a DCAS on ARM due to LL/SC, but
> there are apllications where a DCAS is necessary.

Fwiw, DWCAS operates on two _contiguous_ words. DCAS can work with two
words that are _not_ contiguous. They are completely different
primitives Bonita. Basically, DWCAS on a 64-bit system would be a
128-bit CAS. Now, there is a rather strange function on the Itanium.
cmp8xchg16, its a fun function. :^)

Also, check out the KCSS function from SUN, k-compare single swap:

https://groups.google.com/g/comp.arch/c/shshLdF1uqs/m/VLmZSCBGDTkJ

On 10/25/2023 11:00 AM, Bonita Montero wrote:
> Am 25.10.2023 um 19:09 schrieb Scott Lurndal:
>
>> ARMv8.0 Load Exclusive/Store Exclusive, like LL/SC doesn't scale well
>> and should
>> be avoided.
>
> Maybe it would be nice to have sth. like LL/SC with multiple stores
> to the same cacheline that are buffered until the last store and the
> whole thing fails if the cacheline has been modified or an interrupt
> has happened. I've currently no idea for an actual algorithm using
> a transaction on a whole cacheline but there may be some new kind
> of lock-free programming with that.
>

Transactional memory has been a thorn in my side way back, some decades
ago. Never really liked it. Its prone to live lock, and other issues.
Also, be wary of LL/SC, if you use it wrong it can cause live lock. You
basically have to keep the size of the reservation granule in mind. For
instance, false sharing on a reservation granule can cause live lock.

Am 25.10.2023 um 22:07 schrieb Scott Lurndal:

> https://developer.arm.com/documentation/102873/latest/The-Arm-Transactional-Memory-Extension

Transactional memory goes further than my idea and is rather slow. Thats
while at the end of a transaction all cachelines in the L1 -cache that
have marked as modified will be marked as committed. The idea I had is
simply to buffer all accesses to a _single_ cacheline until the last
conditional store writes to the cacheline.

Am 25.10.2023 um 23:52 schrieb Chris M. Thomasson:

> Transactional memory has been a thorn in my side way back, ...

My idea doesn't go that far like transactional memory but has
the potential to be much faster since the transaction applies
only to a single cacheline.

Am 25.10.2023 um 23:50 schrieb Chris M. Thomasson:

> Fwiw, DWCAS operates on two _contiguous_ words. DCAS can work with
> two words that are _not_ contiguous. They are completely different
> primitives Bonita. Basically, DWCAS on a 64-bit system would be a
> 128-bit CAS. Now, there is a rather strange function on the Itanium.
> cmp8xchg16, its a fun function. :^)

Where did I sth. that was wrong about that ?

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 25.10.2023 um 22:07 schrieb Scott Lurndal:
>
>> https://developer.arm.com/documentation/102873/latest/The-Arm-Transactional-Memory-Extension
>
>Transactional memory goes further than my idea and is rather slow. Thats
>while at the end of a transaction all cachelines in the L1 -cache that
>have marked as modified will be marked as committed. The idea I had is
>simply to buffer all accesses to a _single_ cacheline until the last
>conditional store writes to the cacheline.

https://en.wikipedia.org/wiki/MESI_protocol#Store_Buffer

Am 26.10.2023 um 18:06 schrieb Scott Lurndal:

> Bonita Montero <Bonita.Montero@gmail.com> writes:

>> Transactional memory goes further than my idea and is rather slow. Thats
>> while at the end of a transaction all cachelines in the L1 -cache that
>> have marked as modified will be marked as committed. The idea I had is
>> simply to buffer all accesses to a _single_ cacheline until the last
>> conditional store writes to the cacheline.

> https://en.wikipedia.org/wiki/MESI_protocol#Store_Buffer

You coudln't call my idea a store buffer because the "store buffer"
would be discarded if the cacheline is modified.