| History log of /src/common/lib/libc/arch/aarch64 |
| Revision | Date | Author | Comments |
| 1.5 | 06-Aug-2022 |
riastradh | aarch64: Implement __aarch64_casN_sync.
gcc generates calls to this symbol in programs that use
__sync_*_compare_and_swap, which require full sequential consistency
barriers, including store-before-load ordering on both sides of the
atomic; none of the release/acquire operations guarantee that, so we
have to insert explicit DMB instructions.
Note: gcc's own definition omits some of the DMB instructions, but I
can't prove that it's correct that way -- stores preceding the CAS
must complete before the load part of the CAS, and the store part of
the CAS must complete before loads following the CAS. Maybe there's
some way to prove that one of these orderings is guaranteed some
other way than a DMB but I'm not seeing it, and store-before-load
ordering is hard to understand.
Patch by skrll@ based on a patch by mrg@, soliloquy in commit message
by me.
|
| 1.4 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.3 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 Makefile.inc was added on branch tls-maxphys on 2014-08-19 23:45:11 +0000
|
| 1.7 | 06-Aug-2022 |
riastradh | aarch64: Implement __aarch64_casN_sync.
gcc generates calls to this symbol in programs that use
__sync_*_compare_and_swap, which require full sequential consistency
barriers, including store-before-load ordering on both sides of the
atomic; none of the release/acquire operations guarantee that, so we
have to insert explicit DMB instructions.
Note: gcc's own definition omits some of the DMB instructions, but I
can't prove that it's correct that way -- stores preceding the CAS
must complete before the load part of the CAS, and the store part of
the CAS must complete before loads following the CAS. Maybe there's
some way to prove that one of these orderings is guaranteed some
other way than a DMB but I'm not seeing it, and store-before-load
ordering is hard to understand.
Patch by skrll@ based on a patch by mrg@, soliloquy in commit message
by me.
|
| 1.6 | 23-Jul-2022 |
skrll | whitespace
|
| 1.5 | 18-Jun-2022 |
skrll | be consistent about comparing loaded value against expected old value
register ordering
|
| 1.4 | 18-Jun-2022 |
skrll | Fix some register usage
|
| 1.3 | 16-Jun-2022 |
skrll | remove stray 'w'
|
| 1.2 | 08-Aug-2021 |
skrll | Whitespace
|
| 1.1 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 27-Apr-2021 |
skrll | Provide all the LSE operation fuctions. The use of LSE instructions is
currently disabled.
|
| 1.1 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.2 | 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.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.1 | 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.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_add_16.S was added on branch tls-maxphys on 2014-08-19 23:45:11 +0000
|
| 1.2 | 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.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.1 | 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.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_add_32.S was added on branch tls-maxphys on 2014-08-19 23:45:11 +0000
|
| 1.2 | 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.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.1 | 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.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_add_64.S was added on branch tls-maxphys on 2014-08-19 23:45:11 +0000
|
| 1.2 | 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.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.1 | 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.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_add_8.S was added on branch tls-maxphys on 2014-08-19 23:45:11 +0000
|
| 1.2 | 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.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.1 | 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.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_and_16.S was added on branch tls-maxphys on 2014-08-19 23:45:11 +0000
|
| 1.2 | 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.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.1 | 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.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_and_32.S was added on branch tls-maxphys on 2014-08-19 23:45:11 +0000
|
| 1.2 | 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.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.1 | 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.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_and_64.S was added on branch tls-maxphys on 2014-08-19 23:45:11 +0000
|
| 1.2 | 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.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.1 | 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.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_and_8.S was added on branch tls-maxphys on 2014-08-19 23:45:11 +0000
|
| 1.4 | 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.3 | 07-Oct-2020 |
skrll | Comment nit
|
| 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.1 | 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.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_cas_16.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.4 | 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.3 | 07-Oct-2020 |
skrll | Comment nit
|
| 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.1 | 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.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_cas_32.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.6 | 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.5 | 07-Oct-2020 |
skrll | Comment nit
|
| 1.4 | 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.3 | 19-Feb-2019 |
rin | branches: 1.3.2;
Sort STRONG_ALIAS's in the same manner as ATOMIC_OP_ALIAS's.
No functional changes.
|
| 1.2 | 19-Feb-2019 |
rin | Export _atomic_cas_64 as atomic_cas_64_ni.
Note that _atomic_cas_64 is already exported as atomic_cas_{ulong,prt}_ni.
Fix build error of test/lib/atomic/t_atomic_cas, which is successfully
passed on RPI3B+ now.
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 1.1.26.2 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.1.26.1 | 10-Jun-2019 |
christos | 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_cas_64.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.3.2.1 | 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.4 | 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.3 | 07-Oct-2020 |
skrll | Comment nit
|
| 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.1 | 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.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_cas_8.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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.1 | 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.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_dec_32.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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.1 | 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.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_dec_64.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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.1 | 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.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_inc_32.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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.1 | 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.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_inc_64.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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 | 06-Jul-2021 |
skrll | One more 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.3 | 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.2 | 08-Jul-2021 |
martin | Pull up following revision(s) (requested by skrll in ticket #1319):
common/lib/libc/arch/aarch64/atomic/atomic_nand_16.S: revision 1.4
One more s/pte/ptr/
|
| 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_16.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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
|
| 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_64.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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_8.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.6 | 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.5 | 13-Oct-2020 |
skrll | Remove memory barriers from the atomic ops macros in the same way as was
done for the other atomic ops earlier.
|
| 1.4 | 07-Oct-2020 |
skrll | Comment nit
|
| 1.3 | 08-Feb-2019 |
ryo | branches: 1.3.2;
- atomic_*_{8,16}_nv() must return a new value, not an old value.
- use "dmb sy" for atomic_*{8,16}_nv() in the same way as atomic_*{32,64}_nv().
|
| 1.2 | 06-Feb-2019 |
ryo | fix atomic_sub_*(). it was (delta - *ptr), should be (*ptr - delta).
changing shared macro doesn't effect other atomic_ops because
(*ptr [+|^] delta) and (delta [+|^] *ptr) have same result.
atomic_sub_*() haven't used because non standard API?
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 1.1.26.2 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.1.26.1 | 10-Jun-2019 |
christos | 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_op_asm.h was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.3.2.1 | 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.2 | 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.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.1 | 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.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_or_16.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 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.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.1 | 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.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_or_32.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.3 | 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.2 | 15-Sep-2019 |
skrll | __sync_or_and_fetch_8 should return new value... make it do that.
|
| 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 | 17-Sep-2019 |
martin | Pull up following revision(s) (requested by skrll in ticket #201):
common/lib/libc/arch/aarch64/atomic/atomic_or_64.S: revision 1.2
__sync_or_and_fetch_8 should return new value... make it do that.
|
| 1.1.26.2 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.1.26.1 | 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
| 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_or_64.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 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.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.1 | 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.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_or_8.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 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.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.1 | 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.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_sub_16.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 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.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.1 | 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.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_sub_32.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 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.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.1 | 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.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_sub_64.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 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.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.1 | 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.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_sub_8.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.3 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 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.1 | 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.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_swap_16.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.3 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 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.1 | 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.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_swap_32.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.3 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 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.1 | 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.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_swap_64.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 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 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.3 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 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.1 | 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.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_swap_8.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 21-Apr-2021 |
skrll | Do previous differently as the API is different.
|
| 1.1 | 21-Apr-2021 |
skrll | Provide some more operations that are part of compiler lse.S. This is
incomplete, but at least covers all the atomic_swap ops and allows the
aa64 kernel to link with gcc 10.
|
| 1.2 | 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.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.1 | 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.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_xor_16.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 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.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.1 | 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.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_xor_32.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 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.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.1 | 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.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_xor_64.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 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.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.1 | 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.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_xor_8.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.4 | 09-Apr-2022 |
riastradh | Introduce membar_acquire/release. Deprecate membar_enter/exit.
The names membar_enter/exit were unclear, and the documentation of
membar_enter has disagreed with the implementations on sparc,
powerpc, and even x86(!) for the entire time it has been in NetBSD.
The terms `acquire' and `release' are ubiquitous in the literature
today, and have been adopted in the C and C++ standards to mean
load-before-load/store and load/store-before-store, respectively,
which are exactly the orderings required by acquiring and releasing a
mutex, as well as other useful applications like decrementing a
reference count and then freeing the underlying object if it went to
zero.
Originally I proposed changing one word in the documentation for
membar_enter to make it load-before-load/store instead of
store-before-load/store, i.e., to make it an acquire barrier. I
proposed this on the grounds that
(a) all implementations guarantee load-before-load/store,
(b) some implementations fail to guarantee store-before-load/store,
and
(c) all uses in-tree assume load-before-load/store.
I verified parts (a) and (b) (except, for (a), powerpc didn't even
guarantee load-before-load/store -- isync isn't necessarily enough;
need lwsync in general -- but it _almost_ did, and it certainly didn't
guarantee store-before-load/store).
Part (c) might not be correct, however: under the mistaken assumption
that atomic-r/m/w then membar-w/rw is equivalent to atomic-r/m/w then
membar-r/rw, I only audited the cases of membar_enter that _aren't_
immediately after an atomic-r/m/w. All of those cases assume
load-before-load/store. But my assumption was wrong -- there are
cases of atomic-r/m/w then membar-w/rw that would be broken by
changing to atomic-r/m/w then membar-r/rw:
https://mail-index.netbsd.org/tech-kern/2022/03/29/msg028044.html
Furthermore, the name membar_enter has been adopted in other places
like OpenBSD where it actually does follow the documentation and
guarantee store-before-load/store, even if that order is not useful.
So the name membar_enter currently lives in a bad place where it
means either of two things -- r/rw or w/rw.
With this change, we deprecate membar_enter/exit, introduce
membar_acquire/release as better names for the useful pair (r/rw and
rw/w), and make sure the implementation of membar_enter guarantees
both what was documented _and_ what was implemented, making it an
alias for membar_sync.
While here, rework all of the membar_* definitions and aliases. The
new logic follows a rule to make it easier to audit:
membar_X is defined as an alias for membar_Y iff membar_X is
guaranteed by membar_Y.
The `no stronger than' relation is (the transitive closure of):
- membar_consumer (r/r) is guaranteed by membar_acquire (r/rw)
- membar_producer (w/w) is guaranteed by membar_release (rw/w)
- membar_acquire (r/rw) is guaranteed by membar_sync (rw/rw)
- membar_release (rw/w) is guaranteed by membar_sync (rw/rw)
And, for the deprecated membars:
- membar_enter (whether r/rw, w/rw, or rw/rw) is guaranteed by
membar_sync (rw/rw)
- membar_exit (rw/w) is guaranteed by membar_release (rw/w)
(membar_exit is identical to membar_release, but the name is
deprecated.)
Finally, while here, annotate some of the instructions with their
semantics. For powerpc, leave an essay with citations on the
unfortunate but -- as far as I can tell -- necessary decision to use
lwsync, not isync, for membar_acquire and membar_consumer.
Also add membar(3) and atomic(3) man page links.
|
| 1.3 | 09-Apr-2022 |
riastradh | aarch64/membar_ops: Fix wrong symbol end.
|
| 1.2 | 13-Oct-2020 |
skrll | Use the correct barriers - all of membar_{sync,producer,consumer} have
less scope than before.
LGTM from riastradh
|
| 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.1 | 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.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 membar_ops.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 byte_swap_2.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 byte_swap_4.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 12-Oct-2019 |
maya | Remove htonll and ntohll as symbols from aarch64 libc.
Other architectures do not define them, and so we don't provide a
function declaration in any header.
This means a package may detect it with a link-test and then fail
due to the missing declaration, like sysutils/collectd currently does.
Done this way as aarch64 has not had a release yet. Discussed with releng.
|
| 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.1 | 12-Oct-2019 |
martin | Pull up following revision(s) (requested by maya in ticket #304):
common/lib/libc/arch/aarch64/gen/byte_swap_8.S: revision 1.2
Remove htonll and ntohll as symbols from aarch64 libc.
Other architectures do not define them, and so we don't provide a
function declaration in any header.
This means a package may detect it with a link-test and then fail
due to the missing declaration, like sysutils/collectd currently does.
Done this way as aarch64 has not had a release yet. Discussed with releng.
|
| 1.1.26.2 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.1.26.1 | 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
| 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 byte_swap_8.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.3 | 03-Sep-2020 |
jakllsch | Remove unused assembly source files
|
| 1.2 | 02-Sep-2020 |
jakllsch | Fix typo/pasteo in aarch64 clzdi2() END()
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 clzdi2.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 03-Sep-2020 |
jakllsch | Remove unused assembly source files
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 ctzdi2.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2 | 03-Sep-2020 |
jakllsch | Remove unused assembly source files
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 ffsdi2.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.4 | 07-Feb-2024 |
msaitoh | Remove ryo@'s mail addresses.
|
| 1.3 | 23-Jul-2023 |
skrll | port-arm/57388: Minor bug fix in bcopy.S
Use correct register to check alignment of destination in backwards copy.
Patch from Antoni Pokusinski. Thanks.
|
| 1.2 | 11-Apr-2020 |
ryo | branches: 1.2.8;
Fixed to not use the "br" instruction. Branch Target Identification (BTI) doesn't like "br".
requested by maxv@
|
| 1.1 | 04-Feb-2018 |
skrll | branches: 1.1.4;
Working / new versions from Ryo Shimizu
|
| 1.1.4.3 | 21-Apr-2020 |
martin | Ooops, restore accidently removed files from merge mishap
|
| 1.1.4.2 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.1.4.1 | 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
| 1.2.8.1 | 20-Jul-2024 |
martin | Pull up following revision(s) (requested by rin in ticket #744):
common/lib/libc/arch/aarch64/string/bcopy.S: revision 1.3
port-arm/57388: Minor bug fix in bcopy.S
Use correct register to check alignment of destination in backwards copy.
Patch from Antoni Pokusinski. Thanks.
|
| 1.3 | 09-Jul-2018 |
ryo | avoid reading from out of range that may cause access fault.
|
| 1.2 | 04-Feb-2018 |
skrll | branches: 1.2.2; 1.2.4;
Working / new versions from Ryo Shimizu
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 memcmp.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2.4.3 | 21-Apr-2020 |
martin | Ooops, restore accidently removed files from merge mishap
|
| 1.2.4.2 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.2.4.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.2.2.1 | 28-Jul-2018 |
pgoyette | Sync with HEAD
|
| 1.2 | 04-Feb-2018 |
skrll | branches: 1.2.4;
Working / new versions from Ryo Shimizu
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 memcpy.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2.4.2 | 21-Apr-2020 |
martin | Ooops, restore accidently removed files from merge mishap
|
| 1.2.4.1 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.1 | 04-Feb-2018 |
skrll | branches: 1.1.4;
Working / new versions from Ryo Shimizu
|
| 1.1.4.2 | 21-Apr-2020 |
martin | Ooops, restore accidently removed files from merge mishap
|
| 1.1.4.1 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.3 | 11-Apr-2020 |
ryo | Fixed to not use the "br" instruction. Branch Target Identification (BTI) doesn't like "br".
requested by maxv@
|
| 1.2 | 29-Aug-2017 |
ryo | branches: 1.2.4;
* aarch64/memset.S didn't work! fixed some bugs.
* maximum size of DCZID_EL0:BS (2048) supported.
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 memset.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2.4.3 | 21-Apr-2020 |
martin | Ooops, restore accidently removed files from merge mishap
|
| 1.2.4.2 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.2.4.1 | 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 strcat.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.5 | 09-Sep-2020 |
jakllsch | Re-do previous aarch64eb strlen fix more simply and correctly.
|
| 1.4 | 05-Sep-2020 |
jakllsch | Fix a broken corner case of strlen()/strnlen() on aarch64eb
Previously a string such as "\x1\x1\x1\x1\x1\x1\x1" would count as
0 instead of 7 on BE.
|
| 1.3 | 01-Aug-2018 |
ryo | strnlen(s, (size_t)-1) returned -1. it must return the length of s.
|
| 1.2 | 22-Aug-2017 |
ryo | branches: 1.2.2; 1.2.4;
aarch64/strlen.S didn't work. fixed some bugs.
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 strlen.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
| 1.2.4.3 | 21-Apr-2020 |
martin | Ooops, restore accidently removed files from merge mishap
|
| 1.2.4.2 | 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.2.4.1 | 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.2.2.1 | 06-Sep-2018 |
pgoyette | Sync with HEAD
Resolve a couple of conflicts (result of the uimin/uimax changes)
|
| 1.1 | 10-Aug-2014 |
matt | branches: 1.1.4; 1.1.26;
Preliminary files for AARCH64 (64-bit ARM) support.
Enough for a distribution build.
|
| 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 strnlen.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
|
