msp430-gcc 4.7 bug with shifts?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

msp430-gcc 4.7 bug with shifts?

Daniele Alessandrelli
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: msp430-gcc 4.7 bug with shifts?

Peter Bigot-4
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 <
[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: msp430-gcc 4.7 bug with shifts?

Daniele Alessandrelli
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 <[hidden email]> 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 <
> [hidden email]> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: msp430-gcc 4.7 bug with shifts?

Peter Bigot-4
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 <
[hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]> 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
>>> [hidden email]
>>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: msp430-gcc 4.7 bug with shifts?

Peter Bigot-4
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 <
[hidden email]> 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 <[hidden email]> 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
> > <[hidden email]> 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 <[hidden email]> 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
> >>> <[hidden email]> 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
> >>>> [hidden email]
> >>>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: msp430-gcc 4.7 bug with shifts?

Jhon James
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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]> 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
> > > <[hidden email]> 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 <[hidden email]> 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
> > >>> <[hidden email]> 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
> > >>>> [hidden email]
> > >>>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: msp430-gcc 4.7 bug with shifts?

Peter Bigot-4
mspgcc does not program images onto MSP430s, so updating to 4.7.0 would not
fix the problem.

mspdebug is the tool I use for installing images, but Contiki has
traditionally used the BSL facility over a serial line.  If "make TARGET=z1
hello-world.upload" does not result in the board being programmed you
should contact Zolertia for support.  It may be as simple as updating the
udev rules to recognize the board, and is in any case likely to be a Linux
issue rather than an ARM issue.  You could first test basic serial
functionality by taking a board programmed on the PC that does serial
output and making sure you can plug it into the ARM board and receive that
output.

Questions of this nature really belong on a Zolertia or Contiki support
forum, though.

Peter



On Tue, Jul 9, 2013 at 8:28 PM, Jhon James <[hidden email]> wrote:

> 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 <[hidden email]> 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 <
>> [hidden email]> 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 <[hidden email]> 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
>> > > <[hidden email]> 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 <[hidden email]> 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
>> > >>> <[hidden email]> 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
>> > >>>> [hidden email]
>> > >>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: msp430-gcc 4.7 bug with shifts?

Jhon James
Hello Peter

Thanks for the pointer. Actually I put the same question on the contiki and
tinyOS forum but people suggested me to ask on msp430 mailing list on how
to do the porting on the ARM. I followed this page  (
http://wiki.contiki-os.org/doku.php?id=msp430x) installed msp430 4.7.0 on a
PC. Now i am having a problem code gets compiled easily and gets uploaded
as well but the problem is with the the make login command when i try to
connect to the sensor mote it gets connected but i see garabage of the
serial console.

The Zolertia team has suggested using the TinyProd from the TinyOS writer
but the this works fine but it is precompiled for PC only. you can see this
link (
http://zolertia.sourceforge.net/wiki/index.php/Mainpage:Contiki_installation_Ubuntu
)

I installed the version 4.6.3 msp430-gcc using this  command

apt-get install binutils-msp430 gcc-msp430 msp430-libc msp430mcu
mspdebug ant openjdk-7-jdk


 but this version has the same behaviour of loading and compiling code
sucessfully while make login command returns the garbage on the console. i
think I am close now need some suggestion.

I really appreciate your help

Regard's





On Wed, Jul 10, 2013 at 6:40 AM, Peter Bigot <[hidden email]> wrote:

> mspgcc does not program images onto MSP430s, so updating to 4.7.0 would
> not fix the problem.
>
> mspdebug is the tool I use for installing images, but Contiki has
> traditionally used the BSL facility over a serial line.  If "make TARGET=z1
> hello-world.upload" does not result in the board being programmed you
> should contact Zolertia for support.  It may be as simple as updating the
> udev rules to recognize the board, and is in any case likely to be a Linux
> issue rather than an ARM issue.  You could first test basic serial
> functionality by taking a board programmed on the PC that does serial
> output and making sure you can plug it into the ARM board and receive that
> output.
>
> Questions of this nature really belong on a Zolertia or Contiki support
> forum, though.
>
> Peter
>
>
>
> On Tue, Jul 9, 2013 at 8:28 PM, Jhon James <[hidden email]> wrote:
>
>> 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 <[hidden email]> 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 <
>>> [hidden email]> 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 <[hidden email]> 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
>>> > > <[hidden email]> 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 <[hidden email]> 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
>>> > >>> <[hidden email]> 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
>>> > >>>> [hidden email]
>>> > >>>> 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
>>> [hidden email]
>>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: msp430-gcc 4.7 bug with shifts?

Peter Bigot-4
Once more: this is not an mspgcc problem (or a TinyProd problem), and
certainly has nothing to do with the shift bug in the subject.

Please don't post to mspgcc-users again about this.  (I don't have any Z1
hardware, and don't use ARM as a Contiki development platform, so I can't
help either.)

You need to get support from Contiki or Zolertia or give up on doing
Contiki development for Z1 hardware on an ARM platform.

Peter


On Wed, Jul 10, 2013 at 3:51 PM, Jhon James <[hidden email]> wrote:

> Hello Peter
>
> Thanks for the pointer. Actually I put the same question on the contiki
> and tinyOS forum but people suggested me to ask on msp430 mailing list on
> how to do the porting on the ARM. I followed this page  (
> http://wiki.contiki-os.org/doku.php?id=msp430x) installed msp430 4.7.0 on
> a PC. Now i am having a problem code gets compiled easily and gets uploaded
> as well but the problem is with the the make login command when i try to
> connect to the sensor mote it gets connected but i see garabage of the
> serial console.
>
> The Zolertia team has suggested using the TinyProd from the TinyOS writer
> but the this works fine but it is precompiled for PC only. you can see this
> link (
> http://zolertia.sourceforge.net/wiki/index.php/Mainpage:Contiki_installation_Ubuntu
> )
>
> I installed the version 4.6.3 msp430-gcc using this  command
>
> apt-get install binutils-msp430 gcc-msp430 msp430-libc msp430mcu mspdebug ant openjdk-7-jdk
>
>
>  but this version has the same behaviour of loading and compiling code
> sucessfully while make login command returns the garbage on the console. i
> think I am close now need some suggestion.
>
> I really appreciate your help
>
> Regard's
>
>
>
>
>
> On Wed, Jul 10, 2013 at 6:40 AM, Peter Bigot <[hidden email]> wrote:
>
>> mspgcc does not program images onto MSP430s, so updating to 4.7.0 would
>> not fix the problem.
>>
>> mspdebug is the tool I use for installing images, but Contiki has
>> traditionally used the BSL facility over a serial line.  If "make TARGET=z1
>> hello-world.upload" does not result in the board being programmed you
>> should contact Zolertia for support.  It may be as simple as updating the
>> udev rules to recognize the board, and is in any case likely to be a Linux
>> issue rather than an ARM issue.  You could first test basic serial
>> functionality by taking a board programmed on the PC that does serial
>> output and making sure you can plug it into the ARM board and receive that
>> output.
>>
>> Questions of this nature really belong on a Zolertia or Contiki support
>> forum, though.
>>
>> Peter
>>
>>
>>
>> On Tue, Jul 9, 2013 at 8:28 PM, Jhon James <[hidden email]> wrote:
>>
>>> 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 <[hidden email]> 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 <
>>>> [hidden email]> 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 <[hidden email]> 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
>>>> > > <[hidden email]> 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 <[hidden email]>
>>>> 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
>>>> > >>> <[hidden email]> 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
>>>> > >>>> [hidden email]
>>>> > >>>> 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
>>>> [hidden email]
>>>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: msp430-gcc 4.7 bug with shifts?

Jhon James
Alright sorry about that don't be angry. I will make it work myself. Thanks
for your help

Regard's


On Thu, Jul 11, 2013 at 2:08 AM, Peter Bigot <[hidden email]> wrote:

> Once more: this is not an mspgcc problem (or a TinyProd problem), and
> certainly has nothing to do with the shift bug in the subject.
>
> Please don't post to mspgcc-users again about this.  (I don't have any Z1
> hardware, and don't use ARM as a Contiki development platform, so I can't
> help either.)
>
> You need to get support from Contiki or Zolertia or give up on doing
> Contiki development for Z1 hardware on an ARM platform.
>
> Peter
>
>
> On Wed, Jul 10, 2013 at 3:51 PM, Jhon James <[hidden email]> wrote:
>
>> Hello Peter
>>
>> Thanks for the pointer. Actually I put the same question on the contiki
>> and tinyOS forum but people suggested me to ask on msp430 mailing list on
>> how to do the porting on the ARM. I followed this page  (
>> http://wiki.contiki-os.org/doku.php?id=msp430x) installed msp430 4.7.0
>> on a PC. Now i am having a problem code gets compiled easily and gets
>> uploaded as well but the problem is with the the make login command when i
>> try to connect to the sensor mote it gets connected but i see garabage of
>> the serial console.
>>
>> The Zolertia team has suggested using the TinyProd from the TinyOS writer
>> but the this works fine but it is precompiled for PC only. you can see this
>> link (
>> http://zolertia.sourceforge.net/wiki/index.php/Mainpage:Contiki_installation_Ubuntu
>> )
>>
>> I installed the version 4.6.3 msp430-gcc using this  command
>>
>> apt-get install binutils-msp430 gcc-msp430 msp430-libc msp430mcu mspdebug ant openjdk-7-jdk
>>
>>
>>  but this version has the same behaviour of loading and compiling code
>> sucessfully while make login command returns the garbage on the console. i
>> think I am close now need some suggestion.
>>
>> I really appreciate your help
>>
>> Regard's
>>
>>
>>
>>
>>
>> On Wed, Jul 10, 2013 at 6:40 AM, Peter Bigot <[hidden email]> wrote:
>>
>>> mspgcc does not program images onto MSP430s, so updating to 4.7.0 would
>>> not fix the problem.
>>>
>>> mspdebug is the tool I use for installing images, but Contiki has
>>> traditionally used the BSL facility over a serial line.  If "make TARGET=z1
>>> hello-world.upload" does not result in the board being programmed you
>>> should contact Zolertia for support.  It may be as simple as updating the
>>> udev rules to recognize the board, and is in any case likely to be a Linux
>>> issue rather than an ARM issue.  You could first test basic serial
>>> functionality by taking a board programmed on the PC that does serial
>>> output and making sure you can plug it into the ARM board and receive that
>>> output.
>>>
>>> Questions of this nature really belong on a Zolertia or Contiki support
>>> forum, though.
>>>
>>> Peter
>>>
>>>
>>>
>>> On Tue, Jul 9, 2013 at 8:28 PM, Jhon James <[hidden email]> wrote:
>>>
>>>> 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 <[hidden email]> 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 <
>>>>> [hidden email]> 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 <[hidden email]> 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
>>>>> > > <[hidden email]> 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 <[hidden email]>
>>>>> 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
>>>>> > >>> <[hidden email]> 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
>>>>> > >>>> [hidden email]
>>>>> > >>>> 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
>>>>> [hidden email]
>>>>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users