I did stare at it a little longer this morning and decided it probably did
make sense, though I didn't spend enough time to try to prove it. 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. But at the end I think the primary
effect is it reduces the loop to a single changing variable, which on some
architectures might enable vectorized operations in a subsequent phase of
optimization, or as you suggest simply work better on more common targets.
Or maybe that's not what it's doing. As a philosophico-technical viewpoint
I don't find it useful to speculate about why or how modern compilers
generate the code that they do, and especially not why they don't generate
something else, unless there's clear evidence what they're doing is wrong
(as opposed to just not what I'd have expected). Optimization techniques
these days use advanced number theory that I have never studied and don't
need to know. See, for example, http://www.cloog.org/, which is used in
gcc to do loop optimization through something called "scanning
Z-polyhedra". These techniques do pretty amazing things with pretty
horrible inputs, making my life as a developer much nicer: I can code what
I mean, and let the tools figure out the best way to make it happen. If a
consequence is that they make simple loops look bizarre but still correct
and at a cost no more than the "obvious" alternative without making me fine
tune back-end--specific cost vectors--hey, I can live with that.
Peter
On Wed, Mar 27, 2013 at 7:48 PM, William "Chops" Westfield
<wes...@mac.com>wrote:
> On Mar 27, 2013, at 4:47 AM, Peter Bigot wrote:
>
> > is the code actually wrong?
>
> Good question. I can't tell just by looking at it, you can't tell either.
> I don't think that is a good thing, especially since there is an "obvious"
> translation that looks just as efficient. I'll have to analyze more…
>
> It does look like a newer avr-gcc creates very similar code, so it is
> probably some gcc-level optimization rather than something msp430 specific.
> (Terrific; I'll try to see which incomprehensibly-defined -f option
> controls this optimization. Sigh.)
>
> It looks like it's doing
> // mysteriously initialize temp
> for() {
> if (pwmx + temp < 0)
> led_xxx_off;
> :
> temp = temp + -1;
> }
>
> which will be correct, and probably even better on a truly RISCy CPU (no
> immediate math, no decrement instruction), but it sure looks weird with a
> typical microcontroller instruction set.
>
> BillW
>
>
------------------------------------------------------------------------------
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
