On 26/06/16 17:15, Georg-Johann Lay wrote:
There are quite some standard insns for atomics known to gcc, cf. "atomic_" insns in http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html This can avoid overhead of function calls. But I still don't see the great advantage of using stdatomic over the "classical" util/atomic.h from avr-libc. For C++ we don't have portability because there is no libstdc++ generated for avr, not even libsupc++... Johann
The "classical" atomic locks in util/atomic.h are for constructing critical sections - sections of code that can only be accessed by one context of execution at a time. The stdatomic C11 and C++ atomics are for atomic data - variables that are accessed atomically regardless of contexts. These are two different ways of looking at atomic accesses and correct interrupt or multi-threaded programming. While either can be used to implement the other, they do not replace each other - the best choice depends on the type of code and the type of problem to be solved at the time.
Additionally, it is always good to implement standard solutions - it makes it a lot easier to write code that can be portable between different architectures. So implementing the C11 and C++11 atomics helps make avr-gcc a better tool.
avr-gcc supports a fair amount of C++, even though there are many parts missing (last I looked, which was a good while ago, support for exceptions was missing). People use C++ on the avr, and it makes a lot of sense to support as many features of the latest C++ standards as can conveniently be done. Of course there are many things in C++ that would be disproportionately hard to support on the AVR, and are unlikely to be much used - but if C++11 atomics can be supported "for free" by Jacob's functions added to libatomic to support C11 atomics, then that is a great thing.
mvh., David _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
