Re: MPS430-gcc on Mac...

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
<[email protected]>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&reg; 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users