[libcxx-dev] <atomic> for bare-metal development on ARM microcontrollers

[JF Bastien via libcxx-dev]

I think you want libc++ support for “freestanding”. We’ve discussed this e.g. in “D56913: decoupling Freestanding atomic<T> from	libatomic.a”. Olivier started some of this work for atomic. It sounds like you’d like this work to continue :)

> On Jun 30, 2019, at 8:32 AM, Yves Delley via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> 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
> 
> 
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev