Re: [avr-libc-dev] C11 Atomics and GCC libatomic

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

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

On 24/06/16 22:59, Jacob Moroni wrote: Also, on a somewhat related note, I think there may be a bug in the header, specifically, in the “__iRestore” function which is called to restore the interrupt state after the atomic block is finished. There’s currently a memory barrier after SREG is

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

Jacob Moroni schrieb: Got it. I'll add the support to GCC's libatomic then send it in. Thanks. Here is some introduction on contributing to GCC: http://gcc.gnu.org/contribute.html As it is hard to follow discussions in top-posting style, that style is usually voided :-)

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

Got it. I'll add the support to GCC's libatomic then send it in. Thanks. On Jun 25, 2016 5:13 PM, "Joerg Wunsch" wrote: > As Georg-Johann Lay wrote: > > > As libatomic will need close cooperation with the compiler, I'd > > recommend to add it to GCC. > > That would be my

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

As Georg-Johann Lay wrote: > As libatomic will need close cooperation with the compiler, I'd > recommend to add it to GCC. That would be my recommendation, too. If it's a compile feature, it would better be there. Perhaps it's then even possible to find a more efficient implementation (no

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

Yes, I realize that we're not talking about , but, rather the backend. But, really, my point is that it becomes fairly easy to go all the way ( if desired ) once the backend is in place. Martin Ja McKee On Fri, Jun 24, 2016 at 2:59 PM, Jacob Moroni wrote: > > > To

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

To Markus: I agree that a function call is a fair amount of overhead, especially in the case of single byte operations. The intent wasn’t to eliminate or discourage the use of the existing atomic macros, but rather to provide support for compiling code which uses the portable C11 atomics (or

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

I don't comment often, but... There are, for C++ work, a number of advantages to supporting the standardized atomic types. And, we *are* talking here about C++ support rather than C support, which is rather more lacking in avr-lib-c. Besides making code more portable, the standard atomics

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

Am 24.06.2016 um 16:21 schrieb Jacob Moroni: With this library, I was also able to include a portable version of the header which allows for the successful use of C11 atomic types! I would like to get this merged into avr-libc What's wrong with the atomic macros already existing?

[avr-libc-dev] C11 Atomics and GCC libatomic

Hello, After the C11 spec was finalized, GCC added a bunch of new built-in “__atomic_X” functions to replace the older “__sync_” functions. These atomic functions are generally used by headers, as they were designed to adhere to the C11 memory model, but there’s nothing preventing their use in