Eric forwarded the example to me and I was able to build it, so:
First, WTF1 is apparently gcc attempting to redefine zero for the body of
the loop to be relative to the induction variable. You'd have to do the
algebra to figure out if it's equivalent to the expressions in the code,
but it's outside the loop, so doesn't appear to be a primary issue in
optimization.
For WTF2, is the issue simply that it doesn't make sense on examination, or
is the code actually wrong? If it's wrong, please do reduce it so that
fact is clear and file a bug report. If it functions as specified but just
looks weird, well, I note that the optimized code appears smaller by two
words than the unoptimized code for each PWM test so on the surface mspgcc
is doing what you asked. Best to figure out why gcc might have chosen to
do WTF1, if that's actually relevant.
You'd probably also get a more valid comparison across architectures if you
used something like what's below instead of a call to an external function
which GCC may assume has a pretty high cost, thus changing the parameters
it uses during optimization. Also make sure you're using the same version
of gcc, since the bulk of that optimization is being done by the middle-end
and is mostly independent of target-specific parameters.
Peter
extern volatile unsigned int P4OUT;
#define led_all_on(a) P4OUT |= 0x1F;
#define led1_on P4OUT |= 0x01;
#define led1_off P4OUT &= ~0x01;
#define led2_on P4OUT |= 0x02;
#define led2_off P4OUT &= ~0x02;
#define led3_on P4OUT |= 0x04;
#define led3_off P4OUT &= ~0x04;
#define led4_on P4OUT |= 0x08;
#define led4_off P4OUT &= ~0x08;
#define led5_on P4OUT |= 0x10;
#define led5_off P4OUT &= ~0x10;
On Wed, Mar 27, 2013 at 6:17 AM, Peter Bigot <big...@acm.org> wrote:
> William: Attachments don't work so well on mailing lists; I can't find it
> anywhere, and your excerpt is far too opaque to see what's going on
> ("led1_off;" apparently hides either a function call or an assignment
> statement of some form, but I have no clue what it does or how the data
> objects it accesses are declared). Please do open a ticket at
> https://sourceforge.net/p/mspgcc/bugs/ explaining what you did (compile
> command), what you saw, and what you expected to see. Attach the complete
> standalone example there. Thanks.
>
> Eric: -mcpu, -mmpy, and -mivcnt are the primitive options that control all
> MCU-specific aspects of code generation. -mmcu is simply a key that is
> used by an msp430mcu specs script to select the correct set of those
> options for a specific MCU.
>
> -mmemory-model is a similar helper interface that identifies a specific
> combinations of -msr20, -mc20, -md20, -ma20 which are the primitive options
> controlling all memory-model aspects of code generation.
>
> So yes, -mcpu=430 should work, and it is the appropriate technique when
> building code that is not specific to a particular processor (it's also
> unnecessary, since it's the default; you may want to use -mcpu=430x,
> though). You can see the standard set of primitive combinations by using:
>
> msp430-gcc -print-multi-lib
>
> A standard msp430-libc installation will include archive files optimized
> for each of those cases. There are other combinations but experimentation
> showed it was not worth applying them to msp430-libc.
>
> Peter
>
> On Wed, Mar 27, 2013 at 1:48 AM, Eric Decker <cire...@gmail.com> wrote:
>
>> yeah that looks weird.
>>
>> I don't know how much testing -mcpu=430 has had done on it.
>>
>> All of the testing I've seen and have used myself uses -mmcu=<mcu spec>
>> ie.
>>
>> ie....
>>
>> -mmcu=msp430f1611
>>
>> or
>>
>> -mmcu=msp430f2618
>>
>> or
>>
>> -mmcu=msp430f5438a
>>
>>
>>
>> If that help, submit a bug report and see what Peter says about it.
>>
>>
>> On Tue, Mar 26, 2013 at 11:36 PM, William "Chops" Westfield
>> <wes...@mac.com>wrote:
>>
>> > > If you give me more information about what you are seeing (perhaps
>> send
>> > me the code and how you are invoking the toolchain) I'll see what I can
>> > figure out.
>> >
>> > Sure. I got sucked into a conversation on comparative microcontroller
>> > architectures, and have been providing sample code produced by various
>> PIC
>> > compilers, avr-gcc, and I wanted to add msp430 to the conversation. I
>> > happen to have a simple program that works pretty well as an example,
>> > except I don't understand the code produced when I add optimization.
>> >
>> > I'm using "msp430-gcc -mcpu=430 -Os -c flames.c" (various substitutes
>> for
>> > -Os; all but -O0 seem to have the same weird code.) I've attached the
>> full
>> > program, but the part in question is:
>> >
>> > led_all_on();
>> > for (pwm_delay = 128; pwm_delay !=0; pwm_delay--) {
>> > /*
>> > * We have a random number in each PWM between 1 and 128
>> > * and we're going to have 128 cycles of delay. So each
>> > * decremented output can only cross zero once, at which
>> > * time we toggle the output state.
>> > */
>> > if (--pwm1 == 0) {
>> > led1_off;
>> > }
>> > if (--pwm2 == 0) {
>> > led2_off;
>> > }
>> > if (--pwm3 == 0) {
>> > led3_off;
>> > }
>> >
>> > Which produces:
>> >
>> > 38: b0 12 00 00 call #0x0000 ;; call to all_led_on()
>> > 3c: 45 4b mov.b r11, r5
>> > 3e: 75 50 80 ff add.b #-128, r5 ;; WTF? 1
>> > 42: 46 8b sub.b r11, r6 ;; ...
>> > 44: 47 8b sub.b r11, r7 ;; ...
>> > 46: 48 8b sub.b r11, r8 ;; ...
>> > 48: 49 8b sub.b r11, r9 ;; ...
>> > 4a: 7b 53 add.b #-1, r11 ;r3 As==11 ;; makes
>> > sense if pwm1 is in r11.
>> > 4c: 02 20 jnz $+6
>> > 4e: b0 12 00 00 call #0x0000 ;; call to led1_off
>> > 52: 4f 46 mov.b r6, r15
>> > 54: 4f 5b add.b r11, r15 ;; WTF? 2? It thinks
>> r11
>> > has -1? How? Why?
>> > 56: 02 20 jnz $+6
>> > 58: b0 12 00 00 call #0x0000 ;; call to led2_off
>> > 5c: 4f 47 mov.b r7, r15
>> > 5e: 4f 5b add.b r11, r15
>> > 60: 02 20 jnz $+6
>> > 62: b0 12 00 00 call #0x0000 ;; call to led3_off
>> >
>> > The unoptimized code looks fine, if … unoptimized (size/speed wise,
>> > anyway):
>> >
>> > 5a: b0 12 00 00 call #0x0000 ;; call to all_led_on()
>> > 5e: f4 40 80 ff mov.b #-128, -4(r4)
>> > 62: fc ff
>> > 64: 25 3c jmp $+76
>> > 66: f4 53 f6 ff add.b #-1, -10(r4) ;; add to stack
>> variable
>> > 6a: c4 93 f6 ff tst.b -10(r4) ;0xfff6(r4) ;; check for zero
>> > (unneeded.)
>> > 6e: 02 20 jnz $+6
>> > 70: b0 12 00 00 call #0x0000
>> > 74: f4 53 f7 ff add.b #-1, -9(r4)
>> > 78: c4 93 f7 ff tst.b -9(r4)
>> > 7c: 02 20 jnz $+6
>> > 7e: b0 12 00 00 call #0x0000
>> > 82: f4 53 f8 ff add.b #-1, -8(r4)
>> > 86: c4 93 f8 ff tst.b -8(r4)
>> > 8a: 02 20 jnz $+6
>> > 8c: b0 12 00 00 call #0x0000
>> >
>> > I'd expect to see something like:
>> > call all_led_on
>> > mov.b 128, r5 ;; loop counter
>> > add.b #-1, r6 ;; pwm1 in register
>> > jnz $+6
>> > call led1_off
>> > add.b #-1, r7 ;; pwm2 in register
>> > jnz $+6
>> > call led2_off
>> > ;; etc
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> --
>> Eric B. Decker
>> Senior (over 50 :-) Researcher
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
------------------------------------------------------------------------------
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
