Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

New port: mac68ksf - Macintosh 68k softfloat.

This commit is all the Makefile glue for the new port which is the mac68k
port with MKSOFTFLOAT set to "yes".

As posted here:
https://mail-index.netbsd.org/port-mac68k/2025/10/14/msg001037.html

libc: Define __atomic_is_lock_free.

Limited to architectures where it is actually needed by gcc for any
calls to stdatomic.h atomic_is_lock_free for now.

We should also add it to other architectures too, along with lockful
atomic r/m/w operations for sizes that can't be handled natively, but
that's a lot more work. It is also necessary for -fno-inline-atomics
but we're missing a lot of other symbols for that too, to be fixed.
For now, this should enable the OpenSSL build to complete on these
architectures again after I reverted a local change.

XXX pullup-10

branches: 1.15.14;
Add missing atomic_and_{8,16}_nv_cas.c for __sync_and_and_fetch_{1,2}.
XXX why is not only atomic_and_* symmetric unlike the others?
(in common/lib/libc/atomic/)

branches: 1.14.16;
Add atomic_c11_compare_exchange_cas_{8,16,32}.c

Add missing __sunc_* ops for sun2

Add missing __sync_* ops

Provide _atomic_cas_8_up and _atomic_cas_16_up as assembler functions

invert tests ${MACHINE} != "m68000" -> ${MACHINE} == "m68k"

branches: 1.9.8; 1.9.14; 1.9.18;
allow inclusion of atomic ops in librump

Allow atomic ops to be built as part of libpthread.

Implement _atomic_cas_up() in assembly code as the compiler cannot be
trusted to generate fully restartable code sequences.

Addresses lib/38482 for ARM and m68000.

branches: 1.6.2;
Fix pasto.

Use .c version atomic ops for m68010.

Only build atomic ops for libkern/libc.

Enable the atomic ops in userspace.

branches: 1.2.4;
Pull in m68k atomic ops from the thorpej-atomic branch.

branches: 1.1.2;
file Makefile.inc was initially added on branch thorpej-atomic.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.10.24;
Add aliases for the builtins used to implement C11/C++11 atomics.

branches: 1.9.2;
Try to hide the C runtime implementation specific __sync_* ops from librump,
to avoid duplicates.

Add missing __sync_* ops

Add a few __sync_* and atomic functions.

Add END(func)
Fix some straggling %r@<eol> to (%r)

Convert to normal Motorola syntax for addressing.
%r@ -> (%r)
%r@- -> -(%r)
%r@+ -> (%r)+
%r@(n) n(%r)
etc.
No object differences.

branches: 1.4.2; 1.4.24;
enable profiling of assembly functions.

branches: 1.3.2;
Remove clause 3 and 4 from TNF licenses

branches: 1.2.4; 1.2.8;
Pull in m68k atomic ops from the thorpej-atomic branch.

branches: 1.1.2;
file atomic_add.S was initially added on branch thorpej-atomic.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.11.24;
Add aliases for the builtins used to implement C11/C++11 atomics.

branches: 1.10.2;
Try to hide the C runtime implementation specific __sync_* ops from librump,
to avoid duplicates.

Add missing __sync_* ops

Add END(func)
Fix some straggling %r@<eol> to (%r)

Convert to normal Motorola syntax for addressing.
%r@ -> (%r)
%r@- -> -(%r)
%r@+ -> (%r)+
%r@(n) n(%r)
etc.
No object differences.

branches: 1.6.2; 1.6.24;
enable profiling of assembly functions.

branches: 1.5.2;
Remove clause 3 and 4 from TNF licenses

branches: 1.4.4;
atomic_and/atomic_or don't operate on pointers, so don't copy the return
to a0. From thorpej@.

branches: 1.3.4;
Apparently pointers are also returned in %a0.

Pull in m68k atomic ops from the thorpej-atomic branch.

branches: 1.1.2;
file atomic_and.S was initially added on branch thorpej-atomic.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Introduce __HAVE_M68K_BROKEN_RMC, which can be defined by m68k platforms
that cannot perform indivisible READ-MODIFY-WRITE bus cycles. The
define is named for the /RMC output signal on the CPU that is asserted
when such a cycle is performed. These cycles are only used by the CAS,
CAS2, and TAS instructions. The cycles are, as far as I can tell,
otherwise indistinguishable from garden-variety read followed by write
bus cycles, except for the assertion of /RMC. Note that other single-
instruction "read-modify-write" instructions (e.g. OR, AND, ADD, etc.
with a memory destination operand) do not assert /RMC, and are thus not
considered truly atomic from the perspective of the 68k architecture.

When __HAVE_M68K_BROKEN_RMC is defined, then we must make unavailable
the CAS, CAS2, and TAS instructions, because using them will typically
cause a bus error to occur. In this case, we handle _atomic_cas_32()
(and its aliases) in the kernel environment the same way as the 68010
does: a restartable atomic sequence. 8- and 16-bit CAS operations are
not available in the kernel environment on such platforms.

We define __HAVE_M68K_BROKEN_RMC for the hp300 platform because 68020-based
hp300 systems will generate a fault for /RMC-type cycles.

Based on work by Izumi Tsutsui.

XXX pullup-11?

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.13.16;
fix comment

Improve the code in __sync_bool_compare_and_swap_{1,2,4}.
- bccs is smaller and faster than bcc(.w) in this case.
- it can be used movql in this case (assembler optimise it though).

atomic_cas_{8,16}:
- Correct the wrong offset in stack.
__sync_bool_compare_and_swap_{1,2,4}:
- Correct the wrong offset in stack.
- D3 must be preserved in subroutines.
PR/49995.

branches: 1.10.4;
Try to hide the C runtime implementation specific __sync_* ops from librump,
to avoid duplicates.

Simplify the variants returning a bool

Add a few __sync_* and atomic functions.

Add END(func)
Fix some straggling %r@<eol> to (%r)

Convert to normal Motorola syntax for addressing.
%r@ -> (%r)
%r@- -> -(%r)
%r@+ -> (%r)+
%r@(n) n(%r)
etc.
No object differences.

branches: 1.5.2; 1.5.24;
enable profiling of assembly functions.

branches: 1.4.2;
Remove clause 3 and 4 from TNF licenses

branches: 1.3.4;
Add atomic_cas_foo_ni().

branches: 1.2.4;
Pull in m68k atomic ops from the thorpej-atomic branch.

branches: 1.1.2;
file atomic_cas.S was initially added on branch thorpej-atomic.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.6.26;
Provide _atomic_cas_8_up and _atomic_cas_16_up as assembler functions

Add END(func)
Fix some straggling %r@<eol> to (%r)

Convert to normal Motorola syntax for addressing.
%r@ -> (%r)
%r@- -> -(%r)
%r@+ -> (%r)+
%r@(n) n(%r)
etc.
No object differences.

branches: 1.3.2; 1.3.24;
enable profiling of assembly functions.

branches: 1.2.2; 1.2.4;
Make this compile (missing register prefix).

Implement _atomic_cas_up() in assembly code as the compiler cannot be
trusted to generate fully restartable code sequences.

Addresses lib/38482 for ARM and m68000.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.6.28;
Add END(func)
Fix some straggling %r@<eol> to (%r)

Convert to normal Motorola syntax for addressing.
%r@ -> (%r)
%r@- -> -(%r)
%r@+ -> (%r)+
%r@(n) n(%r)
etc.
No object differences.

branches: 1.4.2; 1.4.24;
enable profiling of assembly functions.

branches: 1.3.2;
Remove clause 3 and 4 from TNF licenses

branches: 1.2.4; 1.2.8;
Pull in m68k atomic ops from the thorpej-atomic branch.

branches: 1.1.2;
file atomic_dec.S was initially added on branch thorpej-atomic.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.6.28;
Add END(func)
Fix some straggling %r@<eol> to (%r)

Convert to normal Motorola syntax for addressing.
%r@ -> (%r)
%r@- -> -(%r)
%r@+ -> (%r)+
%r@(n) n(%r)
etc.
No object differences.

branches: 1.4.2; 1.4.24;
enable profiling of assembly functions.

branches: 1.3.2;
Remove clause 3 and 4 from TNF licenses

branches: 1.2.4; 1.2.8;
Pull in m68k atomic ops from the thorpej-atomic branch.

branches: 1.1.2;
file atomic_inc.S was initially added on branch thorpej-atomic.

Use __sysctl() rather than sysctl() to help with statically-linked
space contrained environments.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.2.4; 1.2.8; 1.2.30;
Try to hide the C runtime implementation specific __sync_* ops from librump,
to avoid duplicates.

Add missing __sync_* ops

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

I am giving up attempting to bend the kernel build machinery to my will
so that assym.h can be safely included by libkern assembly sources. So,
instead, redundantly define __HAVE_M68K_BROKEN_RMC in multiple places so
that all the things that need to key off of it can.

Only include "assym.h" if _KERNEL_OPT is defined.

(Rump strikes again!)

Introduce __HAVE_M68K_BROKEN_RMC, which can be defined by m68k platforms
that cannot perform indivisible READ-MODIFY-WRITE bus cycles. The
define is named for the /RMC output signal on the CPU that is asserted
when such a cycle is performed. These cycles are only used by the CAS,
CAS2, and TAS instructions. The cycles are, as far as I can tell,
otherwise indistinguishable from garden-variety read followed by write
bus cycles, except for the assertion of /RMC. Note that other single-
instruction "read-modify-write" instructions (e.g. OR, AND, ADD, etc.
with a memory destination operand) do not assert /RMC, and are thus not
considered truly atomic from the perspective of the 68k architecture.

When __HAVE_M68K_BROKEN_RMC is defined, then we must make unavailable
the CAS, CAS2, and TAS instructions, because using them will typically
cause a bus error to occur. In this case, we handle _atomic_cas_32()
(and its aliases) in the kernel environment the same way as the 68010
does: a restartable atomic sequence. 8- and 16-bit CAS operations are
not available in the kernel environment on such platforms.

We define __HAVE_M68K_BROKEN_RMC for the hp300 platform because 68020-based
hp300 systems will generate a fault for /RMC-type cycles.

Based on work by Izumi Tsutsui.

XXX pullup-11?

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.5.26;
Remove misplaced #endif

Try to hide the C runtime implementation specific __sync_* ops from librump,
to avoid duplicates.

branches: 1.3.4; 1.3.26;
Remove clause 3 and 4 from TNF licenses

branches: 1.2.4; 1.2.8;
Pull in m68k atomic ops from the thorpej-atomic branch.

branches: 1.1.2;
file atomic_op_asm.h was initially added on branch thorpej-atomic.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.11.24;
Add aliases for the builtins used to implement C11/C++11 atomics.

branches: 1.10.2;
Try to hide the C runtime implementation specific __sync_* ops from librump,
to avoid duplicates.

Add missing __sync_* ops

Add END(func)
Fix some straggling %r@<eol> to (%r)

Convert to normal Motorola syntax for addressing.
%r@ -> (%r)
%r@- -> -(%r)
%r@+ -> (%r)+
%r@(n) n(%r)
etc.
No object differences.

branches: 1.6.2; 1.6.24;
enable profiling of assembly functions.

branches: 1.5.2;
Remove clause 3 and 4 from TNF licenses

branches: 1.4.4;
atomic_and/atomic_or don't operate on pointers, so don't copy the return
to a0. From thorpej@.

branches: 1.3.4;
Apparently pointers are also returned in %a0.

Pull in m68k atomic ops from the thorpej-atomic branch.

branches: 1.1.2;
file atomic_or.S was initially added on branch thorpej-atomic.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.3.4; 1.3.26;
Add aliases for the builtins used to implement C11/C++11 atomics.

branches: 1.2.2; 1.2.4;
Try to hide the C runtime implementation specific __sync_* ops from librump,
to avoid duplicates.

Add missing __sync_* ops

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.9.24;
Add aliases for the C11/C++11 spelling of the CAS primitives.

branches: 1.8.2;
Try to hide the C runtime implementation specific __sync_* ops from librump,
to avoid duplicates.

Add a few __sync_* and atomic functions.

Add END(func)
Fix some straggling %r@<eol> to (%r)

Convert to normal Motorola syntax for addressing.
%r@ -> (%r)
%r@- -> -(%r)
%r@+ -> (%r)+
%r@(n) n(%r)
etc.
No object differences.

branches: 1.4.2; 1.4.24;
enable profiling of assembly functions.

branches: 1.3.2;
Remove clause 3 and 4 from TNF licenses

branches: 1.2.4; 1.2.8;
Pull in m68k atomic ops from the thorpej-atomic branch.

branches: 1.1.2;
file atomic_swap.S was initially added on branch thorpej-atomic.

Rework atomic operations for m68k platforms.

In addition to the 68010 not having a CAS instruction, there are other
68020+ systems that cannot use CAS or TAS because they have non-working
/RMC signal handling. Such systems (for example, 68020-based hp300
systems) will generate a bus error in response.

Combine the 68010's RAS-based CAS implementation with the 68020 CASx-
based implementation, remove the other atomic operations (some of which
use CASx directly), and re-implement all other atomic operations in
terms of _atomic_cas_{8,16,32}(). 68010 always uses the RAS-based
implementation, and non-68010 will check for machdep.broken_rmc at run
time and use the RAS-based implementation if the sysctl succeeds and
returns a non-zero value.

Nix trailing whitespace in files of membars, atomics, and lock stubs.

Will be touching many of these files soon for functional changes.

No functional change intended.

branches: 1.3.4; 1.3.26;
Add aliases for the builtins used to implement C11/C++11 atomics.

branches: 1.2.2; 1.2.4;
Try to hide the C runtime implementation specific __sync_* ops from librump,
to avoid duplicates.

Add missing __sync_* ops