core: Provide all C11 atomic operations#5688
Conversation
8812c3c to
618c595
Compare
| (void) memorder; | ||
| unsigned int mask = irq_disable(); | ||
| memcpy(ret, ptr, size); | ||
| memcpy(ptr, val, size); |
There was a problem hiding this comment.
No line memcpy(val, ret, size);?
There was a problem hiding this comment.
It is implemented as the manual specifies it:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
|
msp430-libc was missing stdatomic.h so I copied Newlib's header and the required support headers to msp430-common (BSD license). Full C11 atomic functionality is still provided when compiling with |
|
Nice! Did you do some codesize comparisons? |
618c595 to
76707eb
Compare
|
@kaspar030 I did not, it's difficult to find anything to compare since the unit tests had to be modified. The emb6 test app saved 28 bytes of ROM on samr21-xpro. Almost nothing was using atomic.h anymore before this PR so its removal was well deserved. |
|
Does this override the GCC buildins which for ARM use LDREX and STREX by default? Instead of disabling and enabling the interrupt? |
|
@DipSwitch GCC only generates library calls if there is no lock-free hardware implementation available. If building for a platform which have atomic operations in hardware then GCC will generate the proper instructions instead (LDREX, STREX on Cortex-M3,M4) You can verify by building the tests-core in |
|
Admittedly, I don't understand most of the changes and thus have a hard time reviewing the changes. Edit: I noticed that the files I have most problems with are imported from newlib. Do we assume those to be correct? |
|
@josephnoir that's OK, I'll reassign. |
|
Kaspar is on vacation, so I need to postpone this one :( |
|
Ping @kaspar030 |
|
ping maintainers! |
…eatures.h Used in msp430-common
be63739 to
f055137
Compare
|
@OlegHahm ping! |
|
I just tested the core unittests on msb-430h, looks good! |
kaspar030
left a comment
There was a problem hiding this comment.
ACK from my side. Thanks for all the work here, must have been awful to keep the "old" platforms supported!
|
Fixes #6491 |
|
Core change needs a second ACK. @melshuber, @OlegHahm, @Kijewski? @kaspar030 Thanks, I have felt responsible for this since I was the one who introduced the old incomplete atomic.h API. It feels nice to finally make the support complete, and also standards compliant. The resulting assembly code for a simple load is quite heavy (see #6491 (comment)), but I guess that's an optimization we can postpone until it becomes an issue. |
melshuber
left a comment
There was a problem hiding this comment.
ACK
One could argue to leave the old API (maybe by calling the implementation) for compaibility issues
|
@melshuber I would prefer to not leave the old implementation in, since it was not really working as intended ( |
|
@gebart well enough, I just wanted to mention it |
This PR adds the remaining
__atomiclibrary functions for C11 support and also provides the__syncfunctions for older GCC versions (msp430).All atomic.h uses in the tree have been replaced by their C11 equivalents.
The functions provided here are only used when the compiler doesn't know how to do a lockless atomic operation for the given target architecture. Therefore, with a recent GCC, most of these functions are only used on Cortex-M0, MSP430.
Note: This PR works fine with
-std=gnu99(the current setting), even though the title says C11