On Sat, Jan 7, 2012 at 10:28 AM, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > On 2012-01-07, Peter Bigot <big...@acm.org> wrote: >> On Sat, Jan 7, 2012 at 9:00 AM, Grant Edwards <grant.b.edwa...@gmail.com> >> wrote: >> >>> It's quite possible that the 4.x compiler is more aggressive about >>> moving stuff around. ?When working on low level stuff like an MSP430, >>> I pretty much always have my Makefiles set up to generate mixed >>> C/assmebly language listings so that it's easy to keep an eye on what >>> the compiler is doing. ?One advantage of that is that you quickly >>> learn what C constructs are handled efficiently by the compiler wand >>> what aren't -- you learn that the smallest, fastest way to do things >>> in C on an MSP430 is not the same as on an AVR. >> >> The 4.x compilers (especially 4.6.x) do optimize much more >> aggressively, but if you use the defined peripheral registers like >> P2OUT mspgcc had better not re-order them across sequence points, >> since those are marked volatile. If you do see something like this, >> it's almost certainly a bug and I'd appreciate it being reported on >> the SF tracker. > > However the "test code" might be non-volatile, and as such GCC is > still free to move it outside the set/clear pair (AFAICT). The GCC > documentaion I've found appears to indicate that the restriction on > moving code across sequence points only affects volatile accesses. > Quoting from > http://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/Volatiles.html#Volatiles > > The minimum either standard specifies is that at a sequence point > all previous accesses to volatile objects have stabilized and no > subsequent accesses have occurred. > > Note that the GCC docs only say that _volatile_ accesses can't be > moved across sequence points. More searches reveal similar statements > along with a few seemingly well-informed postings where it is > explicitly stated that non-volatile accesses may be moved across > sequence points. > > For example from http://blog.regehr.org/archives/28 (which appears to > be a rather well-informed article): > > Summary: Most compilers can and will move accesses to non-volatile > objects around accesses to volatile objects, so don't rely on the > program ordering being respected. > > I don't know if it's still an issue, but at one point he mentions a > "volatile" bug in MSP430: > > Compilers are not totally reliable in their translation of accesses > to volatile-qualified objects. I've written extensively about > this subject elsewhere, but here's a quick example: > > volatile int x; > > void foo (void) { > x = x; > } > > The proper behavior of this code on the actual machine is unambiguous: > there should be a load from x, then a store to it. However, the port > of GCC to the MSP430 processor behaves differently: > > $ msp430-gcc -O vol.c -S -o - > foo: > ret > > [I don't know which version of mspgcc that refers to, and it's not > really related to our topic but it does lead me to believe that the > author knows what he's talking about.]
I believe John was referring to an early patch set applied to LTS-20110716. In fact, he filed that as a bug (https://sourceforge.net/tracker/?func=detail&aid=3399383&group_id=42303&atid=432701), and it was discussion with him that led me to revisit the issue and fix the underlying implementation, even though I chose not to fix that particular problem for that release. See the comments in the tracker entry for more details. > Anyhow.... I can't find anywhere in GCC docs that say non-volatile > accesses can't be moved across sequence points or volatile accesses. > If sequence points and volatile accesses only constrain ordering of > accesses to volatile objects, and what you're timing doesn't involve > volatile objects, then adding sequence points doesn't matter. > > However, adding a memory barrier ought to do the trick. I think. Yes, today I think you're right. In fact, that's what I thought back in early December when I added cycle timing to test430 and found a situation where the compiler helpfully moved the test code out from between the start/stop counter reads. I did something that stopped that from happening, though I don't remember what; it wasn't a memory barrier. Later in December, the topic arose again in the context of the thread at http://gcc.gnu.org/ml/gcc/2011-12/msg00008.html, during which discussion I became convinced any such move was a compiler error, apparently because I mis-read Richard Guenther's response in http://gcc.gnu.org/ml/gcc/2011-12/msg00026.html. The discussion there ultimately revealed an underlying gcc bug that will eventually be fixed in a 4.7.x release, so confusion about the issue is common even among those who are expected to know better. I haven't seen the problem again with mspgcc, but only because I haven't since done timing except around calls to an external function. gcc presumably treats that as a barrier since it can't tell what happens during that call, but I again believe it can happen with inline code and your warning is well-taken. > Pointers to GCC docs actually stating what to expect would be > most welcome... The current version of what you cited (http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html) is the best I know of, and indeed a full memory barrier expressed as: asm volatile ("" : : : "memory"); is what GCC promises to obey. Given mspgcc's old practice of bypassing gcc's volatile validation infrastructure I can't make any promises that even that will work in any release prior to the 4.6.x development series. Thanks for making me revisit this again so I could reset my understanding. When I'm working on it I usually have it right; it's the off-hand comments when I'm focused on some other problem that get me in trouble. Peter ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
