On Sat, Jan 7, 2012 at 9:00 AM, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > On 2012-01-07, David Brown <david.br...@hesbynett.no> wrote: >> On 06/01/12 20:30, Grant Edwards wrote: >>> On 2012-01-06, steve ayer<a...@handhelds.org> wrote: >>> >>>> of course, you could put a wire on an unused gpio pin and put the >>>> device on a scope; that will give you accurate timing of code >>>> segments. >>> >>> In my experience that's usually the easiest method by far... >>> >> >> One thing to watch out for here is that when you write something like: >> >> ... >> setPinHi(); >> test code ... >> setPinLo(); >> ... >> >> you might not be timing all of the test code, or only the test code. >> The compiler can often move the code around the "setPin" statements, >> especially if they are macros or functions that the compiler can see >> during the compilation. > > True. When measuring timings like that it's always a good idea to > have a peek at the assembly to make sure you're measuring what you > think you're measuring. When working with the 3.x msp430 compiler, I > never saw it move any code from inside a set-pin/clear-pin pair to > outside, but it's certainly allowed in many circumstances. You can try > to convice the compiler not to do so by inserting memory barriers or > moving "test code" into a function and calling it, but I've never had > to. > > 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. Prior to resolution of https://sourceforge.net/tracker/index.php?func=detail&aid=3399395&group_id=42303&atid=432701, which is in the current development series but will not be back-ported to 20110716, mspgcc bypassed gcc's volatile semantics infrastructure so it could combine read-modify-write register operations into a single instruction. That approach would occasionally result in a mis-ordered execution sequence. It took some effort to devise a case where that occurred, though, so I wouldn't worry too much about it, though I agree it's worth checking the assembly output if there's any question. Be aware that the assembly patterns produced from C will change as the compiler evolves, so revisit any best-practices learned from mixed C/assembly listings whenever you update your compiler, even within a development series. 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
