[libcxx-dev] <atomic> for bare-metal development on ARM microcontrollers
Yves Delley via libcxx-dev
libcxx-dev at lists.llvm.org
Sun Jun 30 08:32:02 PDT 2019
Dear libc++ developers,
I am experimenting with clang++ together with libc++ on ARM M4
microcontrollers, with the intent to test the viability of the new C++20
coroutines on them (using the -fcoroutines-ts switch of clang). I have
had some moderate success, resulting in a usable toolchain based on the
archetypical newlib C-library:
https://github.com/burnpanck/docker-llvm-armeabi .
However, currently, I build libc++ without threading support, because
I'm targeting bare-metal without RTOS. Unfortunately, that immediately
disables `<atomic>`. This is a pity, because even if there is no
fully-fledged threading available, bare-metal development has to deal
with concurrency in the form of interrupts. Here, library support for
`<atomic>` would be much appreciated.
Is there any particular reason why `<atomic>` needs threading support
under all circumstances? I understand that a library implementation in
absence of compiler intrinsics requires at least a "unique_lock". But on
a microcontroller, one could just disable interrupts for the duration of
the atomic operation, as there is no need for memory synchronisation.
Would it make sense to try detaching atomics from threads to support
vendor supplied atomics, similarly to `<__external_threading>`?
The alternative, trying implement threading support for that target
(with working synchronisation primitives but no actual threads) seems a
much heavier task. At least, it also pulls in the requirement for a
monotonic clock.
I would love to hear your thoughts on the subject.
Thanks and best regards
Yves
More information about the libcxx-dev
mailing list