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
