Re: Discussion: How to handle HALs, SDKs and libraries
On 2023-05-25 01:57, Chris Johns wrote: On 24/5/2023 5:07 pm, Christian MAUDERER wrote: Hello Chris, On 2023-05-24 03:44, Chris Johns wrote: Hi Christian, Thanks for raising this topic. It is a tough one. On 24/5/2023 12:11 am, Kinsey Moore wrote: On Tue, May 23, 2023 at 2:26 AM Christian MAUDERER mailto:christian.maude...@embedded-brains.de>> wrote: Hello, I recently updated the HAL in the i.MXRT BSP. I used the same approach that we use for a lot of similar cases: Import the sources into RTEMS and adapt them slightly so that they work for us. So basically a Clone-and-Own approach. During the discussion of the patches, some concerns were raised, whether we should find a better solution to handle HALs, SDKs and similar cases. We should start discussing a solution that can be used after the 6 release so that maybe someone can start to work on a prototype. Some example cases are: - the mcux_sdk in the imxrt BSP - the hal in the stm32h7 BSP - general ARM CMSIS files - zlib - libfdt One solution could be to build these libraries external and only link RTEMS with them. There are disadvantages to this aproach: - Also in my experience, the API of the HALs / SDKs / libraries seems to be quite stable, it's possible that there are combinations where some unexpected change breaks a driver or makes it impossible to link the applications. Xilinx with the more complex devices like the Versal have been moving things about. The Versal SMC call set is fluid and the PM (platform manager) seems to functionally align to Xilinx tools releases plus Petalinux versions. For example there are stable defined API calls in Versal Linux (XRT/zocl) that depends on PM code that is commented in the code as "to be removed". When I first used the Zynq I used Xilinx's drivers like OAR is currently with the Microblaze. I could not release the results because of the license at the time. I quickly found the drivers lacked functionality for general use and broke under high loads and boundary conditions. The fixes are part of a project and cannot be released because the license at the time made it impossible. What I leant from the exercise is to not depend on their drivers. That sounds like a quite bad case. So it's a good example for that discussion. Thanks for bringing it up. I view the repo as open but not open source ... if that sentence makes sense? I think I understand what you mean. But it's still a good example for the discussion. If a solution theoretically works with that case, it should work with a lot of other cases too. I feel what we considered stable will depend on the origin of the code and that will be case by case. Agreed. - BSPs rely on basic drivers from these libraries (like console or clock driver). If we link against the libraries, the testsuite wouldn't build any more without preinstalled libraries. Yes the mutual dependence if built externally and before RTEMS is not easy to solve. The idea of the HAL code being supplied as .h and a .a does let a user update the drivers without needing an RTEMS version update. Another solution could be to include libraties like that as submodules and build them using the RTEMS build system. We could clone the repos onto the RTEMS git server, and add necessary patches. Advantage would be that it is more similar to the process that we currently have. Another advantage is that we have a known-working version of the files. Upstream updates could be either merged or we could rebase our patches to a new version. See below for the problems this creates. From my point of view, the second option would be the better one especially because we have a tested, fixed version of the library instead telling the user to just use some random version that might or might not work. This is important. We need to define what a release is and it is a requirement we provide all code as tarball files. This implies the release process knows how to create the tarfiles. Regardless which aproach we use: We have to think about how to handle that on releases. In the link aproach (first case), we have to somehow archive source tar balls and some kind of build recipe. In the submodule aproach, we could checkout all submodules and pack the files into the RTEMS release tar ball. So I would expect that the second aproach has less impact here too. Comments? Improvements? Better suggestions? I would definitely prefer the submodule approach over the linking approach to avoid the test issues since some of these HALs bring core functionality. The Xilinx driver framework (embeddedsw repo on Github) would be well-suited to the submodule approach since it is already broken out into the shared driver space because it can apply to at
Re: [PATCHv2 rtems_waf] Allow vendor field in toolchain target triplet
While poking around some more, it seems like there's more places in
this file where assumptions of no vendor in the triplet might come into
play (but did not affect my use of it), if I'm reading it correctly?:
227 conf.env.ARCH_BSP = '%s/%s' % (arch.split('-')[0], bsp)
232 conf.env.RTEMS_ARCH = arch.split('-')[0]
554 return _arch_from_arch_bsp(arch_bsp).split('-')[0]
931 ab = arch_bsp.split('-')
(...)
939 flagstr = subprocess.check_output(
940 [config, '--bsp',
941 '%s/%s' % (ab[0], ab[2]), flags_map[flags]])
I'm also a bit uncertain, what is the "arch" actually supposed to be in
general, given that the _arch_from_arch_bsp(arch_bsp) and
arch(arch_bsp) seem to disagree (former include the os (rtems) field,
latter excludes it).
I'm not sure I am aware of all places where this is used as a
submodule, my only testing has been as part of a custom user
application...
On Thu, 2023-05-25 at 08:48 +1000, Chris Johns wrote:
> Looks good and thanks. I have pushed this.
>
> If you would like to submit module update patches for the various
> repos using
> rtems_waf please feel free to do so.
>
> Chris
>
> On 25/5/2023 4:13 am, Martin Erik Werner wrote:
> > Rework the splitting of arch and bsp to rely on the last field in
> > the
> > arch section starting with "rtems", instead of relying on the arch
> > being
> > exactly two fields in size.
> >
> > This makes sure that toolchains with a vendor field in their target
> > triplet can be used with this build system.
> >
> > Toolchains produced by the RTEMS source builder tend to omit the
> > vendor
> > field, but for example the SPARC LEON/ERC32 toolchain provided by
> > Gaisler through the RCC package does include a vendor field.
> > ---
> >
> > v2 fixes an off-by-one error in list indexing compared to v1.
> >
> > rtems.py | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/rtems.py b/rtems.py
> > index 0b24645..c65a7d2 100644
> > --- a/rtems.py
> > +++ b/rtems.py
> > @@ -858,11 +858,15 @@ def _check_arch_bsps(req, config, path,
> > archs, version):
> >
> >
> > def _arch_from_arch_bsp(arch_bsp):
> > - return '-'.join(arch_bsp.split('-')[:2])
> > + fields = arch_bsp.split('-')
> > + rtems_field_index = next(i for i, field in enumerate(fields)
> > if field.startswith('rtems'))
> > + return '-'.join(fields[:(rtems_field_index + 1)])
> >
> >
> > def _bsp_from_arch_bsp(arch_bsp):
> > - return '-'.join(arch_bsp.split('-')[2:])
> > + fields = arch_bsp.split('-')
> > + rtems_field_index = next(i for i, field in enumerate(fields)
> > if field.startswith('rtems'))
> > + return '-'.join(fields[(rtems_field_index + 1):])
> >
> >
> > def _pkgconfig_path(path):
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCHv2 rtems_waf] Allow vendor field in toolchain target triplet
On 25/5/2023 6:53 pm, martinerikwerner@gmail.com wrote:
> While poking around some more, it seems like there's more places in
> this file where assumptions of no vendor in the triplet might come into
> play (but did not affect my use of it), if I'm reading it correctly?:
>
> 227 conf.env.ARCH_BSP = '%s/%s' % (arch.split('-')[0], bsp)
>
> 232 conf.env.RTEMS_ARCH = arch.split('-')[0]
>
> 554 return _arch_from_arch_bsp(arch_bsp).split('-')[0]
>
> 931 ab = arch_bsp.split('-')
> (...)
> 939 flagstr = subprocess.check_output(
> 940 [config, '--bsp',
> 941 '%s/%s' % (ab[0], ab[2]), flags_map[flags]])
>
> I'm also a bit uncertain, what is the "arch" actually supposed to be in
> general, given that the _arch_from_arch_bsp(arch_bsp) and
> arch(arch_bsp) seem to disagree (former include the os (rtems) field,
> latter excludes it).
I suspect the uncertainly is due to things evolving and me not paying close
enough attention because it did not matter. The vendor field changes that. I
will take a look and see if I can clean it up.
What is the full text for the `arch_bsp` you are working with so I can test it?
> I'm not sure I am aware of all places where this is used as a
> submodule, my only testing has been as part of a custom user
> application...
Oh nice to hear. I will look through the repos we have and look at updating
them.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Unify
On 25/5/2023 3:54 pm, Sebastian Huber wrote: > On 25.05.23 03:40, Kinsey Moore wrote:> Is there any reason this isn't just > being moved to a shared directory if >> they're all being made identical? > > Initially, they were all identical. We already have a shared implementation > > https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/cpustdatomic.h > > The CPU port specific allows a custom implementation > if needed. I would keep this ability. > Why not just add the file back if it is needed when it is needed and then remove it once it is not? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Unify
On 26/5/2023 1:38 pm, Andy wrote: > > If you need my reply, I am ok to switch to BSD-2-Clause license. > Thank you and thank you for letting us know. :) Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] termios: Add
Add which does not depend on to
provide rtems_termios_device_context and rtems_termios_device_handler.
For polled serial device drivers, this removes a header file dependency
to the full file system support.
---
bsps/arm/xilinx-zynq/console/console-init.c | 1 +
bsps/include/dev/serial/zynq-uart.h | 2 +-
bsps/shared/dev/serial/zynq-uart.c | 1 +
cpukit/include/rtems/libio.h| 2 +-
cpukit/include/rtems/termiosdevice.h| 300
cpukit/include/rtems/termiostypes.h | 244 +---
cpukit/libcsupport/src/termiosinitialize.c | 11 +-
7 files changed, 314 insertions(+), 247 deletions(-)
create mode 100644 cpukit/include/rtems/termiosdevice.h
diff --git a/bsps/arm/xilinx-zynq/console/console-init.c
b/bsps/arm/xilinx-zynq/console/console-init.c
index 5eb69dc224..72fa27da11 100644
--- a/bsps/arm/xilinx-zynq/console/console-init.c
+++ b/bsps/arm/xilinx-zynq/console/console-init.c
@@ -26,6 +26,7 @@
*/
#include
+#include
#include
#include
diff --git a/bsps/include/dev/serial/zynq-uart.h
b/bsps/include/dev/serial/zynq-uart.h
index 245c6d2afc..e7854af5f1 100644
--- a/bsps/include/dev/serial/zynq-uart.h
+++ b/bsps/include/dev/serial/zynq-uart.h
@@ -34,7 +34,7 @@
#ifndef LIBBSP_ARM_XILINX_ZYNQ_UART_H
#define LIBBSP_ARM_XILINX_ZYNQ_UART_H
-#include
+#include
#ifdef __cplusplus
extern "C" {
diff --git a/bsps/shared/dev/serial/zynq-uart.c
b/bsps/shared/dev/serial/zynq-uart.c
index 10e5d2acff..390ee1f527 100644
--- a/bsps/shared/dev/serial/zynq-uart.c
+++ b/bsps/shared/dev/serial/zynq-uart.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
diff --git a/cpukit/include/rtems/libio.h b/cpukit/include/rtems/libio.h
index cb0e6879a9..6898168aa6 100644
--- a/cpukit/include/rtems/libio.h
+++ b/cpukit/include/rtems/libio.h
@@ -1360,7 +1360,7 @@ typedef struct {
/**
* @brief Parameter block for open/close.
*/
-typedef struct {
+typedef struct rtems_libio_open_close_args {
rtems_libio_t *iop;
uint32_tflags;
uint32_tmode;
diff --git a/cpukit/include/rtems/termiosdevice.h
b/cpukit/include/rtems/termiosdevice.h
new file mode 100644
index 00..146510c457
--- /dev/null
+++ b/cpukit/include/rtems/termiosdevice.h
@@ -0,0 +1,300 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup TermiostypesSupport
+ *
+ * @brief This header file provides the interfaces of the
+ * @ref TermiostypesSupport.
+ */
+
+/*
+ * Copyright (C) 2014, 2017 embedded brains GmbH & Co. KG
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTEMS_TERMIOSDEVICE_H
+#define _RTEMS_TERMIOSDEVICE_H
+
+#include
+#include
+
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+struct rtems_libio_open_close_args;
+struct rtems_termios_tty;
+struct termios;
+
+/**
+ * @defgroup TermiostypesSupport RTEMS Termios Device Support
+ *
+ * @ingroup libcsupport
+ *
+ * @brief This group contains the Termios Device Support provided by RTEMS.
+ */
+
+/**
+ * @brief Termios device context.
+ *
+ * @see RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER(),
+ * rtems_termios_device_context_initialize() and
+ * rtems_termios_device_install().
+ */
+typedef struct rtems_termios_device_context {
+ union {
+/* Used for TERMIOS_POLLED and TERMIOS_IRQ_DRIVEN */
+rtems_interrupt_lock interrupt;
+
+/* Used for TERMIOS_IRQ_SERVER_DRIVEN or TERMIOS_TASK_DRIVEN */
+rtems_mutex mutex;
+ } lock;
+
+ void ( *lock_acquire )(
+struct rtems_termios_device_context *,
+rtems_interrupt_lock_context *
+ );
+
+ void ( *lock_release )(
+struct rtems_termios_device_context
[PATCH 1/2] score: Remove CPU port specific cpuatomic.h
All CPU ports used the same header file to
provide the atomic operations. Remove the header file indirection.
---
.../score/{cpustdatomic.h => cpuatomic.h} | 0
.../aarch64/include/rtems/score/cpuatomic.h | 42 ---
.../cpu/arm/include/rtems/score/cpuatomic.h | 33 ---
.../cpu/bfin/include/rtems/score/cpuatomic.h | 14 ---
.../cpu/i386/include/rtems/score/cpuatomic.h | 33 ---
.../cpu/lm32/include/rtems/score/cpuatomic.h | 14 ---
.../cpu/m68k/include/rtems/score/cpuatomic.h | 33 ---
.../include/rtems/score/cpuatomic.h | 41 --
.../cpu/mips/include/rtems/score/cpuatomic.h | 33 ---
.../cpu/moxie/include/rtems/score/cpuatomic.h | 33 ---
.../cpu/nios2/include/rtems/score/cpuatomic.h | 33 ---
.../cpu/or1k/include/rtems/score/cpuatomic.h | 33 ---
.../powerpc/include/rtems/score/cpuatomic.h | 33 ---
.../cpu/riscv/include/rtems/score/cpuatomic.h | 31 --
.../cpu/sh/include/rtems/score/cpuatomic.h| 14 ---
.../cpu/sparc/include/rtems/score/cpuatomic.h | 33 ---
.../sparc64/include/rtems/score/cpuatomic.h | 33 ---
.../cpu/v850/include/rtems/score/cpuatomic.h | 33 ---
.../x86_64/include/rtems/score/cpuatomic.h| 14 ---
19 files changed, 533 deletions(-)
rename cpukit/include/rtems/score/{cpustdatomic.h => cpuatomic.h} (100%)
delete mode 100644 cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/i386/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/lm32/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/m68k/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/microblaze/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/mips/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/moxie/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/nios2/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/or1k/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/powerpc/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/riscv/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/sh/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/sparc/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/sparc64/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/v850/include/rtems/score/cpuatomic.h
delete mode 100644 cpukit/score/cpu/x86_64/include/rtems/score/cpuatomic.h
diff --git a/cpukit/include/rtems/score/cpustdatomic.h
b/cpukit/include/rtems/score/cpuatomic.h
similarity index 100%
rename from cpukit/include/rtems/score/cpustdatomic.h
rename to cpukit/include/rtems/score/cpuatomic.h
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
deleted file mode 100644
index ed8091d73c..00
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
+++ /dev/null
@@ -1,42 +0,0 @@
-/* SPDX-License-Identifier: BSD-2-Clause */
-
-/**
- * @file
- *
- * @ingroup RTEMSScoreCPU
- *
- * @brief AArch64 Atomics support
- */
-
-/*
- * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
- * Written by Kinsey Moore
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
- * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- */
-
-#ifndef _RTEMS_SCORE_ATOMIC_CPU_H
-#define _RTEMS_SCORE_ATOMIC_CPU_H
-
-#include
-
-#endif /* _
[PATCH 2/2] score: Remove CPU port atomic operations API
Use the C/C++ standard API directly.
---
cpukit/include/rtems/score/atomic.h| 962 ++--
cpukit/include/rtems/score/cpuatomic.h | 986 -
2 files changed, 888 insertions(+), 1060 deletions(-)
delete mode 100644 cpukit/include/rtems/score/cpuatomic.h
diff --git a/cpukit/include/rtems/score/atomic.h
b/cpukit/include/rtems/score/atomic.h
index 161b0ec03e..9ef1779e60 100644
--- a/cpukit/include/rtems/score/atomic.h
+++ b/cpukit/include/rtems/score/atomic.h
@@ -10,6 +10,7 @@
*/
/*
+ * Copyright (C) 2015 embedded brains GmbH & Co. KG
* COPYRIGHT (c) 2012-2013 Deng Hengyi.
*
* Redistribution and use in source and binary forms, with or without
@@ -37,7 +38,7 @@
#ifndef _RTEMS_SCORE_ATOMIC_H
#define _RTEMS_SCORE_ATOMIC_H
-#include
+#include
/**
* @defgroup RTEMSScoreAtomic Atomic Operations
@@ -54,122 +55,935 @@
* @{
*/
-typedef CPU_atomic_Uint Atomic_Uint;
+#ifdef RTEMS_SMP
+ #if defined(__cplusplus) \
+&& (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9))
+/*
+ * The GCC 4.9 ships its own which is not C++ compatible.
The
+ * suggested solution was to include in case C++ is used. This
works
+ * at least with GCC 4.9. See also:
+ *
+ * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
+ * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60940
+ */
+#include
+#define _RTEMS_SCORE_ATOMIC_USE_ATOMIC
+ #else
+#include
+#define _RTEMS_SCORE_ATOMIC_USE_STDATOMIC
+ #endif
+#else
+ #include
+#endif
-typedef CPU_atomic_Ulong Atomic_Ulong;
+#if defined(_RTEMS_SCORE_ATOMIC_USE_ATOMIC)
-typedef CPU_atomic_Uintptr Atomic_Uintptr;
+typedef std::atomic_uint Atomic_Uint;
-typedef CPU_atomic_Flag Atomic_Flag;
+typedef std::atomic_ulong Atomic_Ulong;
-typedef CPU_atomic_Order Atomic_Order;
+typedef std::atomic_uintptr_t Atomic_Uintptr;
-#define ATOMIC_ORDER_RELAXED CPU_ATOMIC_ORDER_RELAXED
+typedef std::atomic_flag Atomic_Flag;
-#define ATOMIC_ORDER_ACQUIRE CPU_ATOMIC_ORDER_ACQUIRE
+typedef std::memory_order Atomic_Order;
-#define ATOMIC_ORDER_RELEASE CPU_ATOMIC_ORDER_RELEASE
+#define ATOMIC_ORDER_RELAXED std::memory_order_relaxed
-#define ATOMIC_ORDER_ACQ_REL CPU_ATOMIC_ORDER_ACQ_REL
+#define ATOMIC_ORDER_ACQUIRE std::memory_order_acquire
-#define ATOMIC_ORDER_SEQ_CST CPU_ATOMIC_ORDER_SEQ_CST
+#define ATOMIC_ORDER_RELEASE std::memory_order_release
-#define ATOMIC_INITIALIZER_UINT( value ) CPU_ATOMIC_INITIALIZER_UINT( value )
+#define ATOMIC_ORDER_ACQ_REL std::memory_order_acq_rel
-#define ATOMIC_INITIALIZER_ULONG( value ) CPU_ATOMIC_INITIALIZER_ULONG( value )
+#define ATOMIC_ORDER_SEQ_CST std::memory_order_seq_cst
-#define ATOMIC_INITIALIZER_UINTPTR( value ) CPU_ATOMIC_INITIALIZER_UINTPTR(
value )
+#define ATOMIC_INITIALIZER_UINT( value ) ATOMIC_VAR_INIT( value )
-#define ATOMIC_INITIALIZER_FLAG CPU_ATOMIC_INITIALIZER_FLAG
+#define ATOMIC_INITIALIZER_ULONG( value ) ATOMIC_VAR_INIT( value )
-#define _Atomic_Fence( order ) _CPU_atomic_Fence( order )
+#define ATOMIC_INITIALIZER_UINTPTR( value ) ATOMIC_VAR_INIT( value )
-#define _Atomic_Init_uint( obj, desired ) \
- _CPU_atomic_Init_uint( obj, desired )
+#define ATOMIC_INITIALIZER_FLAG ATOMIC_FLAG_INIT
-#define _Atomic_Init_ulong( obj, desired ) \
- _CPU_atomic_Init_ulong( obj, desired )
+#elif defined(_RTEMS_SCORE_ATOMIC_USE_STDATOMIC)
-#define _Atomic_Init_uintptr( obj, desired ) \
- _CPU_atomic_Init_uintptr( obj, desired )
+typedef atomic_uint Atomic_Uint;
-#define _Atomic_Load_uint( obj, order ) \
- _CPU_atomic_Load_uint( obj, order )
+typedef atomic_ulong Atomic_Ulong;
-#define _Atomic_Load_ulong( obj, order ) \
- _CPU_atomic_Load_ulong( obj, order )
+typedef atomic_uintptr_t Atomic_Uintptr;
-#define _Atomic_Load_uintptr( obj, order ) \
- _CPU_atomic_Load_uintptr( obj, order )
+typedef atomic_flag Atomic_Flag;
-#define _Atomic_Store_uint( obj, desr, order ) \
- _CPU_atomic_Store_uint( obj, desr, order )
+typedef memory_order Atomic_Order;
-#define _Atomic_Store_ulong( obj, desr, order ) \
- _CPU_atomic_Store_ulong( obj, desr, order )
+#define ATOMIC_ORDER_RELAXED memory_order_relaxed
-#define _Atomic_Store_uintptr( obj, desr, order ) \
- _CPU_atomic_Store_uintptr( obj, desr, order )
+#define ATOMIC_ORDER_ACQUIRE memory_order_acquire
-#define _Atomic_Fetch_add_uint( obj, arg, order ) \
- _CPU_atomic_Fetch_add_uint( obj, arg, order )
+#define ATOMIC_ORDER_RELEASE memory_order_release
-#define _Atomic_Fetch_add_ulong( obj, arg, order ) \
- _CPU_atomic_Fetch_add_ulong( obj, arg, order )
+#define ATOMIC_ORDER_ACQ_REL memory_order_acq_rel
-#define _Atomic_Fetch_add_uintptr( obj, arg, order ) \
- _CPU_atomic_Fetch_add_uintptr( obj, arg, order )
+#define ATOMIC_ORDER_SEQ_CST memory_order_seq_cst
-#define _Atomic_Fetch_sub_uint( obj, arg, order ) \
- _CPU_atomic_Fetch_sub_uint( obj, arg, order )
+#define ATOMIC_INITIALIZER_UINT( value ) ATOMIC_VAR_INIT( value )
-#define _Atomic_
