| History log of /src/common/lib/libc/arch/aarch64/atomic/atomic_nand_32.S |
| Revision | | Date | Author | Comments |
| 1.5 |
| 29-Jul-2021 |
skrll | As we're providing the legacy gcc __sync built-in functions for atomic
memory access we might as well get the memory barriers right...
From the gcc documentation:
In most cases, these built-in functions are considered a full barrier.
That is, no memory operand is moved across the operation, either forward
or backward. Further, instructions are issued as necessary to prevent the
processor from speculating loads across the operation and from queuing
stores after the operation.
type __sync_lock_test_and_set (type *ptr, type value, ...)
This built-in function is not a full barrier, but rather an acquire
barrier. This means that references after the operation cannot move to
(or be speculated to) before the operation, but previous memory stores
may not be globally visible yet, and previous memory loads may not yet
be satisfied.
void __sync_lock_release (type *ptr, ...)
This built-in function is not a full barrier, but rather a release
barrier. This means that all previous memory stores are globally
visible, and all previous memory loads have been satisfied, but
following memory reads are not prevented from being speculated to
before the barrier.
|
| 1.4 |
| 05-Jul-2021 |
skrll | typo in comment s/pte/ptr/
|
| 1.3 |
| 04-Jul-2021 |
skrll | Fix the logic operation for atomic_nand_{8,16,32,64}
From the gcc docs the operations are as follows
{ tmp = *ptr; *ptr = ~(tmp & value); return tmp; } // nand
{ tmp = ~(*ptr & value); *ptr = tmp; return *ptr; } // nand
yes, this is really rather strange.
|
| 1.2 |
| 12-Aug-2020 |
skrll | Part I of ad@'s performance improvements for aarch64
- Remove memory barriers from the atomic ops. I don't understand why those
are there. Is it some architectural thing, or for a CPU bug, or just
over-caution maybe? They're not needed for correctness.
- Have unlikely conditional branches go forwards to help the static branch
predictor.
|
| 1.1 |
| 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26; 1.1.28;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 1.1.28.2 |
| 11-Aug-2021 |
martin | Pull up following revision(s) (requested by skrll in ticket #1331):
common/lib/libc/arch/aarch64/atomic/atomic_add_8.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_sub_8.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_sub_64.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_swap_64.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_swap_64.S: revision 1.5
common/lib/libc/arch/aarch64/atomic/atomic_inc_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_or_64.S: revision 1.3
common/lib/libc/arch/aarch64/atomic/atomic_and_16.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_xor_64.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_and_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_nand_8.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_add_64.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_op_asm.h: revision 1.5
common/lib/libc/arch/aarch64/atomic/atomic_swap_8.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_op_asm.h: revision 1.6
common/lib/libc/arch/aarch64/atomic/atomic_cas_64.S: revision 1.4
common/lib/libc/arch/aarch64/atomic/atomic_nand_8.S: revision 1.5
common/lib/libc/arch/aarch64/atomic/atomic_sub_16.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_cas_64.S: revision 1.6
common/lib/libc/arch/aarch64/atomic/atomic_swap_8.S: revision 1.5
common/lib/libc/arch/aarch64/atomic/atomic_sub_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_swap_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_nand_64.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_swap_16.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_xor_8.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_swap_32.S: revision 1.5
common/lib/libc/arch/aarch64/atomic/atomic_or_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_nand_64.S: revision 1.5
common/lib/libc/arch/aarch64/atomic/atomic_swap_16.S: revision 1.5
common/lib/libc/arch/aarch64/atomic/atomic_or_8.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_or_16.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_cas_16.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_xor_16.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_cas_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_cas_16.S: revision 1.4
common/lib/libc/arch/aarch64/atomic/atomic_add_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_cas_8.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_xor_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_dec_64.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_cas_32.S: revision 1.4
common/lib/libc/arch/aarch64/atomic/atomic_add_16.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_cas_8.S: revision 1.4
common/lib/libc/arch/aarch64/atomic/membar_ops.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_nand_16.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_nand_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_nand_16.S: revision 1.5
common/lib/libc/arch/aarch64/atomic/atomic_nand_32.S: revision 1.5
common/lib/libc/arch/aarch64/atomic/atomic_inc_64.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_dec_32.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_and_8.S: revision 1.2
common/lib/libc/arch/aarch64/atomic/atomic_and_64.S: revision 1.2
Part I of ad@'s performance improvements for aarch64
- Remove memory barriers from the atomic ops. I don't understand why thos=
e
are there. Is it some architectural thing, or for a CPU bug, or just
over-caution maybe? They're not needed for correctness.
- Have unlikely conditional branches go forwards to help the static branch
predictor.
Remove memory barriers from the atomic ops macros in the same way as was
done for the other atomic ops earlier.
Use the correct barriers - all of membar_{sync,producer,consumer} have
less scope than before.
LGTM from riastradh
As we're providing the legacy gcc __sync built-in functions for atomic
memory access we might as well get the memory barriers right...
From the gcc documentation:
In most cases, these built-in functions are considered a full barrier.
That is, no memory operand is moved across the operation, either forward
or backward. Further, instructions are issued as necessary to prevent the
processor from speculating loads across the operation and from queuing
stores after the operation.
type __sync_lock_test_and_set (type *ptr, type value, ...)
This built-in function is not a full barrier, but rather an acquire
barrier. This means that references after the operation cannot move to
(or be speculated to) before the operation, but previous memory stores
may not be globally visible yet, and previous memory loads may not yet
be satisfied.
void __sync_lock_release (type *ptr, ...)
This built-in function is not a full barrier, but rather a release
barrier. This means that all previous memory stores are globally
visible, and all previous memory loads have been satisfied, but
following memory reads are not prevented from being speculated to
before the barrier.
|
| 1.1.28.1 |
| 06-Jul-2021 |
martin | Pull up following revision(s) (requested by skrll in ticket #1314):
common/lib/libc/arch/aarch64/atomic/atomic_nand_8.S: revision 1.3
common/lib/libc/arch/aarch64/atomic/atomic_nand_8.S: revision 1.4
common/lib/libc/arch/aarch64/atomic/atomic_nand_64.S: revision 1.3
common/lib/libc/arch/aarch64/atomic/atomic_nand_64.S: revision 1.4
common/lib/libc/arch/aarch64/atomic/atomic_nand_16.S: revision 1.3
common/lib/libc/arch/aarch64/atomic/atomic_nand_32.S: revision 1.3
common/lib/libc/arch/aarch64/atomic/atomic_nand_32.S: revision 1.4
Fix the logic operation for atomic_nand_{8,16,32,64}
From the gcc docs the operations are as follows
{ tmp = *ptr; *ptr = ~(tmp & value); return tmp; } // nand
{ tmp = ~(*ptr & value); *ptr = tmp; return *ptr; } // nand
yes, this is really rather strange.
typo in comment s/pte/ptr/
|
| 1.1.26.2 |
| 21-Apr-2020 |
martin | Ooops, restore accidently removed files from merge mishap
|
| 1.1.26.1 |
| 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.1.4.2 |
| 19-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
| 1.1.4.1 |
| 10-Aug-2014 |
tls | file atomic_nand_32.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
