On 07/01/12 16:00, Grant Edwards 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. >
That's exactly what I was referring 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. > With each generation, gcc is getting smarter - so it becomes increasingly important to understand the subtleties of the C rules to make sure your code is correct. As Peter says, don't rely too much on what makes the best code. I fully agree that generating assembly listings and looking at them from time to time is useful - and for occasional pieces of code that must be as fast as possible, it's essential. But normally it's enough to have a good understanding of your processor - if it's an 8-bit target, prefer uint8_t over uint16_t, while for a 16-bit target you should typically prefer uint16_t (or perhaps uint_fast8_t for portability). It's generally not worth trying to figure out if a "while loop" or a "for loop" is faster on a particular target - it can change over time, and sometimes hand-optimising your C code gives worse results in the end. (A common case for that is converting array accesses to pointer code - it used to be a good trick for speed, but now it typically limits the compiler's optimiser more than it helps.) ------------------------------------------------------------------------------ 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
