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 <
daniele.alessandre...@gmail.com> 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 <big...@acm.org> 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
> > <daniele.alessandre...@gmail.com> 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 <big...@acm.org> 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
> >>> <daniele.alessandre...@gmail.com> 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
> >>>> Mspgcc-users@lists.sourceforge.net
> >>>> 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
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
