Please see my answer at the bottom. W dniu 2016-12-09 09:15:24 użytkownik David Brown <da...@westcontrol.com> napisał: > On 08/12/16 21:55, Marcin Godlewski wrote: > > > > > > W dniu 2016-12-08 21:46:40 użytkownik Georg-Johann Lay <a...@gjlay.de> > > napisał: > >> Marcin Godlewski schrieb: > >>> Dear all, > >>> > >>> Thanks for the reply to David. However I'm not trying to find a solution > >>> for the described issue. What I'm trying to say in this e-mail is that > >>> this part of Atmel documentation: > >>> http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reorder.html > >>> is innacurate and should be corrected. The conclusion says: > >>> > >>> memory barriers ensure proper ordering of volatile accesses > >>> > >>> memory barriers don't ensure statements with no volatile accesses to > >>> be reordered across the barrier > >>> > >>> while it should say: > >>> > >>> memory barriers ensure proper ordering of global variables accesses > >>> > >>> memory barriers don't ensure local variables accesses to be reordered > >>> across the barrier > >> > >> At least the "local" vs. "global" is not completely correct. After > >> all it's about memory accesses, and it doesn't matter if the memory > >> is local (e.g. local static) or if you are dereferencing a pointer > >> (which might point to a local auto or to an object on heap). > > > > Ok, let's define it "global" vs "automatic". After all it is all > > about the possibility that the memory can be shared. Global variables > in > general can be shared, automatic variables cannot. But for sure > > it's not the matter of volatile. A barrier that orders only volatile > > accesses is a nonsense - this is already guaranteed by the volatile > > itself. > > Local variables that are only in registers, or are optimised away, are > still "automatic" and are unaffected by memory barriers. And it is not > always easy to know whether a variable has gone in memory or not. Even > if you take the address of a local variable, it may never move from a > register if the compiler can find a way to avoid it. > > Memory barriers will affect all data that is in memory, and that can be > legally accessed as memory from within an assembly statement. So global > (or file static) data is definitely ordered by a memory clobber, > regardless of whether or not it is volatile. Local variables whose > /address/ has "escaped" (i.e., been assigned to global data, passed to > external functions, etc.) are also ordered. Local variables which > remain local need not be ordered, I believe. > > What the page here should really be saying here is that memory barriers > do not order /operations/ or /calculations/, only memory accesses. > > Does that help? > > > >
Yes, I find your description understandable, exhaustive and accurate. So the site should be corrected, preferably both here: http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder and here: http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reorder.html Anyone knows who maintains the sites? Thanks and regards, Marcin _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list