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 I don't know whether this group is the right place to post it however I do not know any better place. Hope someone here can trigger the change of the documentation and I also hope to be corrected if I am wrong. Thanks and regards, Marcin W dniu 2016-12-08 13:10:29 użytkownik David Brown <da...@westcontrol.com> napisał: > On 07/12/16 00:42, Marcin Godlewski wrote: > > Dear all, > > > > I'm writing with reference to the following paragraph in avr libc manual: > > http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder > > > > It is stated there: "However, memory barrier works well in ensuring that > > all volatile accesses before and after the barrier occur in the given > > order with respect to the barrier. However, it does not ensure the > > compiler moving non-volatile-related statements across the barrier. > > Peter Dannegger provided a nice example of this effect:(...)". The text > > is followed by an example. > > There /is/ a good (IMHO) solution to this without using unnecessary > memory stores: > > #define cli() __asm volatile( "cli" ::: "memory" ) > #define sei() __asm volatile( "sei" ::: "memory" ) > unsigned int ivar; > void test2( unsigned int val ) > { > val = 65535U / val; > asm volatile("" :: "" (val)); > cli(); > ivar = val; > sei(); > } > > The assembly here tells the compiler that we are going to use "val", so > it must be available before "executing" the assembly line. But since > the assembly line does nothing, no extra work is involved - nothing is > stored or loaded unnecessarily. > > For my own use, I have it in a macro. There is also a macro here that > tells the compiler to "forget" what it knows about a variable - the > compiler needs to know it's state before the assembly (since the > asssembly "uses" it), and it needs to assume that the assembly might > change it. But again, no unnecessary code is generated, and the > variables can happily remain in registers all the time. > > > // Ensure that "val" has been calculated before next volatile access > // by requiring it as an assembly input. Note that only volatiles are > ordered! > #define forceDependency(val) \ > asm volatile("" :: "" (val) : ) > > // Tell the compiler that it no longer knows about "v", without actually > changing it. > // This can be used to break relationships or ranges that the compiler > knows due > // to array information, type-based analysis, etc. > #define forgetCompilerKnowledge(v) \ > asm volatile ("" : "+g" (v)) > > > > > > My understanding of the example is that what _probably_ made the > > operation being moved accross the barrier is that it involved only local > > data. This example doesn't show that any operations on global data can > > be moved accross the barrier. I think that the conclusion that a barrier > > prevents only operations on volatile data from being reordered accross > > the barrier is wrong. No operation on global data should be reordered > > accross the barrier, even on non-volatile data. But apparently, > > operations on local data can, which by the way makes some sense. > > > > The definition of a barrier ensuring that "all volatile accesses before > > and after the barrier occur in the given order with respect to the > > barrier" doesn't make much sense as this is already guaranteed by the C > > language standard. Per standard, any operations on volatile variables > > must be evaluated according to the rules of the abstract machine. > > > > Please let me know what is your view on the subject. > > > > Best regards,Marcin Godlewski > > > > > > > > > > _______________________________________________ > > AVR-GCC-list mailing list > > AVR-GCC-list@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/avr-gcc-list > > > > _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list