On Mar 27, 2013, at 6:21 PM, Peter Bigot wrote: > For a while there I thought it might be finding the minimum pwm value and > eliminating the iterations up to that value from the loop--which it's > entitled to do given what was coded.
That's a discouraging thought. How would I prevent this from happening? Making the pwm_delay loop counter volatile resulted in the avr compiler (which is actually based on 4.6.2) generating the more obvious code, but the msp430 code stayed "obscure." Binary searching through the optimization options… -fno-ivopts turns this off for the avr compiler, but not for msp430. -fno-tree-loop-optimize turns this off for both avr and msp430. the only somewhat readable description I found of just what -ftree-loop-optimize is likely to do is here: http://gcc.gnu.org/onlinedocs/gccint/Tree-SSA-passes.html , and it implies that it does rather a lot of things that are generally a good idea. Although in this case it definitely ends up producing slower and bigger code. Ah, well. Thanks for your help; I mostly wanted confirmation that I wasn't using some known buggy version of the compiler before trying to delve too deeply into what was going on. Does this warrant a bug for the resulting poorer-than-possible optimization? Thanks Bill W ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
