Re: msp430-gcc 4.7 bug with shifts?

Hello Peter,

I have previously used the Contiki with Z1 motes on a PC. I used msp430-gcc
and everything worked quite well. I have now an embedded ARM board on which
I am trying to install the msp430-gcc compiler. The board comes with Ubuntu
installed it it. I tried installed msp430-gcc 4.63 on it but it did not
worked for me since motes cannot be programmed using it. It is reommended
to use msp430-gcc 4.7.0 I tried but did not suceeded can you share some to
follow or packages to install. Since you are using contiki

I appreciate your pointers

Thanks


On Thu, Jul 4, 2013 at 8:13 PM, Peter Bigot <[email protected]> wrote:

> I'm still analyzing Contiki's mac/rdc/radio layers, and won't be looking at
> CoAP for a while.  But I see generally what's going on there; it's probably
> a separate bug that only shows up now that the first one has been fixed.
>
> It'll take a couple days to get back to this.
>
> Peter
>
>
> On Thu, Jul 4, 2013 at 9:38 AM, Daniele Alessandrelli <
> [email protected]> wrote:
>
> > Thank you for the quick patch.
> > However, there are still some problems. For example, when I compile
> > the attached code (sorry, I can't replicate the problem with simple
> > code), I get the following error:
> > /tmp/ccNaHhxW.s: Assembler messages:
> > /tmp/ccNaHhxW.s:1427: Error: Repeated instruction must have register
> > mode operands
> >
> > The problematic code snippet is from line 699 to 706:
> > ...
> >         case COAP_OPTION_BLOCK1:
> >           coap_pkt->block1_num = coap_parse_int_option(current_option,
> > option_len);
> >           coap_pkt->block1_more = (coap_pkt->block1_num & 0x08)>>3;
> >           coap_pkt->block1_size = 16 << (coap_pkt->block1_num & 0x07);
> >           coap_pkt->block1_offset = (coap_pkt->block1_num &
> > ~0x0000000F)<<(coap_pkt->block1_num & 0x07);
> >           coap_pkt->block1_num >>= 4;
> >           printf("Block1 [%lu%s (%u B/blk)]\n", coap_pkt->block1_num,
> > coap_pkt->block1_more ? "+" : "", coap_pkt->block1_size);
> >           break;
> > ...
> >
> > Part of the produced assembly code is the following:
> > ...
> >         mov     r12, r4
> >         and     #7, r4
> >         mov.b   r4, r11
> >         mov     #16, @r1
> >         cmp.b   #0, r11
> >         jeq     .L158
> >         add.b   #-1, r11
> >         .rpt    r11
> >         rlax    @r1
> > .L158:
> >         mov     @r1, 96(r9)
> > ...
> >
> > The invalid instruction seems to be the following
> > .rpt    r11
> > rlax    @r1
> >
> > Some notes:
> > - the code is taken from Contiki, so perhaps you can test it personally
> > - if the final printf() is removed, the code compiles (i.e., the
> > generated assembly is correct) and works as expected.
> >
> > Regards.
> >
> > Daniele
> >
> > On Wed, Jul 3, 2013 at 8:30 PM, Peter Bigot <[email protected]> wrote:
> > > Thanks for the ticket and the reproducing code.  I've attached to the
> > ticket
> > > a (second attempt at a) patch that I believe fixes this.  It has not
> > > undergone significant testing but I'll be using it in my own work.
> > >
> > > Those of you playing along at home might find the patch attached to
> > > https://sourceforge.net/p/mspgcc/bugs/352/ useful as well.  They are
> to
> > the
> > > 20120911 development release, and are unsupported, but are most of what
> > > would have qualified as patches if that were an LTS release.  If you
> > apply
> > > them and build a system, please update the version number in some way
> so
> > > you're reminded they're not standard builds.
> > >
> > > Sorry, I don't provide instructions or support for applying patches to
> > > mspgcc.
> > >
> > > Peter
> > >
> > >
> > > On Wed, Jul 3, 2013 at 11:38 AM, Daniele Alessandrelli
> > > <[email protected]> wrote:
> > >>
> > >> I opened the ticket:
> > >> https://sourceforge.net/p/mspgcc/bugs/357/
> > >>
> > >> Thank you for your time.
> > >>
> > >> Daniele
> > >>
> > >>
> > >> On Wed, Jul 3, 2013 at 5:20 PM, Peter Bigot <[email protected]> wrote:
> > >>>
> > >>> That looks like a bug.  Only happens on CPUX architectures.  If you
> > open
> > >>> up a ticket on https://sourceforge.net/p/mspgcc/bugs/ I may be able
> > to look
> > >>> at it some time.
> > >>>
> > >>> Peter
> > >>>
> > >>>
> > >>> On Wed, Jul 3, 2013 at 7:37 AM, Daniele Alessandrelli
> > >>> <[email protected]> wrote:
> > >>>>
> > >>>> Hi everybody,
> > >>>>
> > >>>> I noticed a strange behavior when executing certain shift operations
> > and
> > >>>> I
> > >>>> wonder whether this is because of a compiler bug or just my
> ignorance
> > in
> > >>>> low-level C.
> > >>>>
> > >>>> For example, when compiling (with no optimization) and then
> executing
> > >>>> the
> > >>>> following lines of code the result I obtain is 16 instead of 64:
> > >>>>
> > >>>> uint32_t  u32_var;
> > >>>>
> > >>>> int main(void)
> > >>>> {
> > >>>>     int tmp;
> > >>>>     ...
> > >>>>     u32_var = 0xa;
> > >>>>     tmp = 16 << (u32_var & 0x07);
> > >>>>     printf("tmp: %d\n", tmp);
> > >>>>     ...
> > >>>> }
> > >>>>
> > >>>> However, if I change the type of tmp form "int" to "unsigned int"
> the
> > >>>> result is correct (i.e., 64).
> > >>>>
> > >>>> This is assembly code generated when tmp is defined as int (i.e.,
> when
> > >>>> the
> > >>>> result is wrong).
> > >>>>
> > >>>>     5c44:       b2 40 0a 00     mov     #10,    &0x1c02 ;#0x000a
> > >>>>
> > >>>>     5c48:       02 1c
> > >>>>
> > >>>>     5c4a:       82 43 04 1c     mov     #0,     &0x1c04 ;r3 As==00
> > >>>>
> > >>>>     5c4e:       1e 42 02 1c     mov     &0x1c02,r14
> > >>>>
> > >>>>     5c52:       1f 42 04 1c     mov     &0x1c04,r15
> > >>>>
> > >>>>     5c56:       0f 4e           mov     r14,    r15
> > >>>>
> > >>>>     5c58:       3f f0 07 00     and     #7,     r15     ;#0x0007
> > >>>>
> > >>>>     5c5c:       3e 40 10 00     mov     #16,    r14     ;#0x0010
> > >>>>
> > >>>>     5c60:       4f 4f           mov.b   r15,    r15
> > >>>>
> > >>>>     5c62:       7f f0 0f 00     and.b   #15,    r15     ;#0x000f
> > >>>>
> > >>>>     5c66:       84 4e fc ff     mov     r14,    -4(r4)  ;0xfffc(r4)
> > >>>>
> > >>>>     5c6a:       4f 93           tst.b   r15
> > >>>>
> > >>>>     5c6c:       03 24           jz      $+8             ;abs 0x5c74
> > >>>>
> > >>>>     5c6e:       7f 53           add.b   #-1,    r15     ;r3 As==11
> > >>>>
> > >>>>     5c70:       cf 18 0e 5e     .rpt    r15
> > >>>>
> > >>>>                                 addx    r14,    r14
> > >>>>
> > >>>>     5c74:       14 12 fc ff     push    -4(r4)          ;0xfffc(r4)
> > >>>>
> > >>>>     5c78:       30 12 9a 66     push    #26266          ;#0x669a
> > >>>>
> > >>>>     5c7c:       b0 12 ae 5c     call    #0x5cae
> > >>>>
> > >>>>
> > >>>> As you can see, at address 0x5c66, register 14 (containing 16) is
> > stored
> > >>>> in
> > >>>> memory before being shifted. The stored valued (i.e., 16) is then
> > pushed
> > >>>> in
> > >>>> the stack (i.e., passed as an argument to the printf() function).
> > >>>>
> > >>>> I have a similar problem also when using -Os, but I can't replicate
> it
> > >>>> with
> > >>>> simple code because of the optimization. However, if needed, I can
> > post
> > >>>> the
> > >>>> (large) source code that is giving me this problem.
> > >>>>
> > >>>> The version of msp430-gcc that I am using is:
> > >>>> msp430-gcc (GCC) 4.7.0 20120322 (mspgcc dev 20120911)
> > >>>>
> > >>>> Thank you for any help you can provide.
> > >>>>
> > >>>> Regards.
> > >>>>
> > >>>> Daniele
> > >>>>
> > >>>>
> > >>>>
> >
> ------------------------------------------------------------------------------
> > >>>> This SF.net email is sponsored by Windows:
> > >>>>
> > >>>> Build for Windows Store.
> > >>>>
> > >>>> http://p.sf.net/sfu/windows-dev2dev
> > >>>> _______________________________________________
> > >>>> Mspgcc-users mailing list
> > >>>> [email protected]
> > >>>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> > >>>>
> > >>>
> > >>
> > >
> >
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk

_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users