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
