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 <jakemor...@gmail.com> 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 <martinjaymc...@gmail.com> > 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 <m...@jump-ing.de> 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 >> > AVR-libc-dev@nongnu.org >> > https://lists.nongnu.org/mailman/listinfo/avr-libc-dev >> > >> _______________________________________________ >> AVR-libc-dev mailing list >> AVR-libc-dev@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/avr-libc-dev >> > > _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
