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

[Martin McKee]

Yes, I realize that we're not talking about <atomic>, 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 <address@hidden> wrote:

>
>
> 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 the somewhat portable GCC __atomic_X functions
> directly). Routines which require absolute speed and efficiency would still
> be best suited using the existing macros, but I think providing support for
> the standard/GCC atomics could be useful. There are some routines such as
> “__atomic_compare_exchange” [1] which are pretty convenient since you can
> use the result as an expression. To accomplish the same task using the
> existing macros would require you to end up implementing a function anyway
> in many cases. Another (slight) advantage of using a function call is that
> it prevents operations on register-stored variables from “leaking” into the
> atomic block and causing interrupts to be disabled for a longer time than
> expected [2].
>
>
>
> Also, on a somewhat related note, I think there may be a bug in the
> <avr/atomic.h> 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 restored, but I think the
> barrier should be before in order to ensure that any pending stores are
> completed _before_ restoring the interrupt state. If the barrier is after,
> I’m not sure if there’s anything preventing operations on non-volatile
> variables from being reordered with respect to the restoring of SREG.
>
>
>
> It’s likely that this problem has never been encountered in the field
> because the common practice is to declare all shared globals as “volatile”,
> which therefore prevents accesses to them from being reordered with respect
> to access of SREG, but it seems like a possible issue to me.
>
>
>
> If you agree, I can submit a bug report or even make the fix myself once I
> figure out the process of sending in a patch. This is actually my first
> time participating in any type of collaborative open source project!
>
>
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
>
>
>
> [2]
> http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reorder.html
>
>
>
>
>
> To Martin:
>
>
>
> In this case, I was talking specifically about the C11 atomics that are
> defined in <stdatomic.h> rather than the C++11 atomics which I believe are
> defined in <atomic>. There is also another header in C++ called
> <cstdatomic> which is apparently the C++ version of the C11 atomic header.
> That being said, the proposed library implements the backend support
> required for all of these headers, so they could likely all be implemented
> (or grabbed from any other license compliant source) if need be, and I
> would be glad to do it if you think it would be useful.
>
>
>
> I still have some more testing to do involving the library, but I will
> post it on my Github within the next day or so. If the higher powers agree
> to accept this contribution, they can either grab it from my Github or I
> can send it in. I will just need some guidance as to how to officially
> submit a patch/contribution. While I’m not new at programming, I am new to
> the whole “contributing to open source software” thing!
>
>
>
> - Jake
>
> On Fri, Jun 24, 2016 at 3:43 PM, Martin McKee <address@hidden>
> wrote:
>
>> 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 library works in a well
>> quantified manner and is, thus, safer for someone that moves between
>> different platforms.  Plus, the C++ standard atomic functionality has a
>> much wider range of granularity than the current avr-libc atomic header.
>> It is possible to protect blocks of code, but, moreover, atomic types
>> allow
>> for *type-safe* atomic access to single values with only minimal periods
>> of
>> interrupts being disabled.  Granted, this is entirely possible with a
>> block
>> critical section, but the code is much more complicated than the direct
>> value access of the "atomic type."
>>
>> Finally, the C++ atomics are typically, and this is what Jacob is
>> describing above, I believe, implemented with a combination of compiler
>> intrensics and template metaprogramming.  The result is that there is no
>> function call.  The code is inlined, just like a macro.  As such, there is
>> no additional cost
>>
>> I for one would welcome this as an addition to the current library.
>>
>> Martin Jay McKee
>>
>> On Fri, Jun 24, 2016 at 10:02 AM, Markus Hitter <address@hidden> wrote:
>>
>> > Am 24.06.2016 um 16:21 schrieb Jacob Moroni:
>> >
>> >> With this library, I was also able to include a portable version of the
>> >> <stdatomic.h> 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?
>> >
>> > http://www.nongnu.org/avr-libc/user-manual/atomic_8h.html
>> >
>> > A function call is rather heavyweight for something as simple as locking
>> > interrupts.
>> >
>> > As the above macros require C99, Teacup Firmware created a similar macro
>> > set working on C89, too:
>> >
>> >
>> https://github.com/Traumflug/Teacup_Firmware/blob/master/memory_barrier.h
>> >
>> >
>> > Markus
>> >
>> > --
>> > - - - - - - - - - - - - - - - - - - -
>> > Dipl. Ing. (FH) Markus Hitter
>> > http://www.jump-ing.de/
>> >
>> >
>> > _______________________________________________
>> > AVR-libc-dev mailing list
>> > address@hidden
>> > https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>> >
>> _______________________________________________
>> AVR-libc-dev mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>>
>
>