Wayne Thornton commented on a discussion on cpukit/include/rtems/dhrl.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150442 > +/* SPDX-License-Identifier: BSD-2-Clause */ > + > +/** > + * @file > + * > + * @brief Deterministic Hedged Read Library (DHRL) Public API > + * > + * @note This library is explicitly constrained to x86_64/amd64 > architectures. @gedare I've refactored the implementation to completely decouple the core DHRL logic from the underlying hardware, removing the hardcoded limitations from cpukit. I dropped all inline `x86_64` assembly (`clflush, pause, rdtsc`) out of the core library files and moved the architecture-specific behavior behind two low-level hooks inside `score/cpu`: `_CPU_DHRL_Relax() `(handles pipeline stalling/execution backoff) `_CPU_DHRL_Cache_Invalidate()` (handles precise line cache clearing) To control this cleanly at compile time, I added a feature macro: `CPU_HAS_DHRL_HOOKS`. The library now compiles universally across the entire RTEMS tree using a basic feature-gate pattern: On supported targets, like `x86_64` the architecture defines `CPU_HAS_DHRL_HOOKS` in its respective `score/cpu.h`. The compiler inline-expands these hooks into their native assembly blocks. On unsupported targets, if `CPU_HAS_DHRL_HOOKS` is undefined, the library falls back to standard stubs, and `dhrl_init()` immediately returns `RTEMS_NOT_IMPLEMENTED`. I updated the tests `smpdhrl01` and `smpdhrl02` to catch this status code and call `TEST_END()` gracefully. On unsupported targets, the tests will simply log an architectural skip and pass, in theory keeping the global CI builds green. At the moment, this API is targeted towards `x86_64` boards that support `RTEMS_SMP`. However, other architectures can (and do) support dynamic hedged reads (i.e. Graviton) but the implementation would be on a case-by-case basis. This initial merge is intended to make the entry to the codebase, with ongoing development. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150442 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
