Re: MPS430-gcc on Mac...

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 <[email protected]> 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
> <[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
>
>

------------------------------------------------------------------------------
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