Loading ...
Sorry, an error occurred while loading the content.

Re: [trimedia] Conflict due to violation of restricted pointer assumption

Expand Messages
  • Chuck Peplinski
    Do you get a warning telling you of possible aliasing of restricted pointers? You told the compiler that these pointers do not alias, so the result is
    Message 1 of 5 , Jun 8, 2006
    View Source
    • 0 Attachment
      Do you get a warning telling you of possible aliasing of restricted
      pointers? You told the compiler that these pointers do not alias, so
      the result is certainly undefined.

      Chuck Peplinski
      TriMedian at MDS www.mds.com


      Chris Bore wrote:
      >
      > That is deliberately breaking things. :-)
      >
      > I am pretty sure the result is 'undefined' but I do not know what
      > happens in practice.
      >
      > A nice example of a logic bomb, though.
      >
      > Chris
      >
      > ======
      > Chris Bore
      > chris@... <mailto:chris%40bores.com>
      >
      > -----Original Message-----
      > From: "Ahmad Hassan"<ahmad.hassan@...
      > <mailto:ahmad.hassan%40streaming-networks.com>>
      > Sent: 08/06/06 09:13:43
      > To: "trimedia@yahoogroups.com
      > <mailto:trimedia%40yahoogroups.com>"<trimedia@yahoogroups.com
      > <mailto:trimedia%40yahoogroups.com>>
      > Subject: [trimedia] Conflict due to violation of restricted pointer
      > assumption
      > Dear All,
      >
      > I came across an interesting question regarding violation of "restrict
      > assumption". Attached is an example.
      > The answer in this case turns out to be 5 (on the simulator), could
      > have been 6. I may as well say that the answer is undefined.
      >
      > Does anybody have an idea how does the DSPCPU handle the case when we
      > try to write different values to same memory location in the same
      > cycle. How does the hardware handle this conflict?
      >
      > ... Just an academic sort of query, don't have any good reason to do so.
      >
      >
      > main()
      > {
      > int a, b;
      > writeConflict(&a, &a);
      > printf("%d",a);
      > }
      >
      > int writeConflict(int *restrict a, int *restrict b)
      > {
      > *a=5; *b=6;
      > }
      >
      > (* cycle 0 *)
      > IF r1 iaddi(0x6) r0 -> r8 (* alu/Op7 *),
      > IF r1 ijmpt r1 r2,
      >
      >
      > [Message truncated. Tap Edit->Mark for Download to get remaining portion.]
      >
      >


      [Non-text portions of this message have been removed]
    • Ahmad Hassan
      Dear Chuck, I don t get a warning and I know the result is undefined. My question is how the hardware handle this situation. To explain a little further, note
      Message 2 of 5 , Jun 8, 2006
      View Source
      • 0 Attachment
        Dear Chuck,

        I don't get a warning and I know the result is undefined. My question is how the hardware handle this situation. To explain a little further,
        note that the address generation logic will be generating same address and the CPU will try to write different values to same address.
        My limited knowledge of hardware tells me that I am short circuiting something, I am trying to put 1 and 0 simultanously in the least significant bit of that location. Thus, the software has created problem for the hardware.

        Now, how does the hardware handle it, I am curious to know.

        Kind regards,
        -Ahmad




        ----- Original Message -----
        From: Chuck Peplinski
        To: trimedia@yahoogroups.com
        Sent: Thursday, June 08, 2006 7:57 PM
        Subject: Re: [trimedia] Conflict due to violation of restricted pointer assumption


        Do you get a warning telling you of possible aliasing of restricted
        pointers? You told the compiler that these pointers do not alias, so
        the result is certainly undefined.

        Chuck Peplinski
        TriMedian at MDS www.mds.com

        Chris Bore wrote:
        >
        > That is deliberately breaking things. :-)
        >
        > I am pretty sure the result is 'undefined' but I do not know what
        > happens in practice.
        >
        > A nice example of a logic bomb, though.
        >
        > Chris
        >
        > ======
        > Chris Bore
        > chris@... <mailto:chris%40bores.com>
        >
        > -----Original Message-----
        > From: "Ahmad Hassan"<ahmad.hassan@...
        > <mailto:ahmad.hassan%40streaming-networks.com>>
        > Sent: 08/06/06 09:13:43
        > To: "trimedia@yahoogroups.com
        > <mailto:trimedia%40yahoogroups.com>"<trimedia@yahoogroups.com
        > <mailto:trimedia%40yahoogroups.com>>
        > Subject: [trimedia] Conflict due to violation of restricted pointer
        > assumption
        > Dear All,
        >
        > I came across an interesting question regarding violation of "restrict
        > assumption". Attached is an example.
        > The answer in this case turns out to be 5 (on the simulator), could
        > have been 6. I may as well say that the answer is undefined.
        >
        > Does anybody have an idea how does the DSPCPU handle the case when we
        > try to write different values to same memory location in the same
        > cycle. How does the hardware handle this conflict?
        >
        > ... Just an academic sort of query, don't have any good reason to do so.
        >
        >
        > main()
        > {
        > int a, b;
        > writeConflict(&a, &a);
        > printf("%d",a);
        > }
        >
        > int writeConflict(int *restrict a, int *restrict b)
        > {
        > *a=5; *b=6;
        > }
        >
        > (* cycle 0 *)
        > IF r1 iaddi(0x6) r0 -> r8 (* alu/Op7 *),
        > IF r1 ijmpt r1 r2,
        >
        >
        > [Message truncated. Tap Edit->Mark for Download to get remaining portion.]
        >
        >

        [Non-text portions of this message have been removed]





        [Non-text portions of this message have been removed]
      • Chuck Peplinski
        Maybe Luis will be able to answer. I would assume that one or the other happens and the other is discarded. I would be much surprised to find any sort of bus
        Message 3 of 5 , Jun 8, 2006
        View Source
        • 0 Attachment
          Maybe Luis will be able to answer. I would assume that one or the other
          happens and the other is discarded. I would be much surprised to find
          any sort of bus contention or problem in the chip. The pipeline has no
          interlocks, so the only thing that happens is the result is not what you
          expected.

          C

          Chuck Peplinski
          TriMedian at MDS www.mds.com



          Ahmad Hassan wrote:
          >
          > Dear Chuck,
          >
          > I don't get a warning and I know the result is undefined. My question
          > is how the hardware handle this situation. To explain a little further,
          > note that the address generation logic will be generating same address
          > and the CPU will try to write different values to same address.
          > My limited knowledge of hardware tells me that I am short circuiting
          > something, I am trying to put 1 and 0 simultanously in the least
          > significant bit of that location. Thus, the software has created
          > problem for the hardware.
          >
          > Now, how does the hardware handle it, I am curious to know.
          >
          > Kind regards,
          > -Ahmad
          >
          > ----- Original Message -----
          > From: Chuck Peplinski
          > To: trimedia@yahoogroups.com <mailto:trimedia%40yahoogroups.com>
          > Sent: Thursday, June 08, 2006 7:57 PM
          > Subject: Re: [trimedia] Conflict due to violation of restricted
          > pointer assumption
          >
          > Do you get a warning telling you of possible aliasing of restricted
          > pointers? You told the compiler that these pointers do not alias, so
          > the result is certainly undefined.
          >
          > Chuck Peplinski
          > TriMedian at MDS www.mds.com
          >
          > Chris Bore wrote:
          > >
          > > That is deliberately breaking things. :-)
          > >
          > > I am pretty sure the result is 'undefined' but I do not know what
          > > happens in practice.
          > >
          > > A nice example of a logic bomb, though.
          > >
          > > Chris
          > >
          > > ======
          > > Chris Bore
          > > chris@... <mailto:chris%40bores.com> <mailto:chris%40bores.com>
          > >
          > > -----Original Message-----
          > > From: "Ahmad Hassan"<ahmad.hassan@...
          > <mailto:ahmad.hassan%40streaming-networks.com>
          > > <mailto:ahmad.hassan%40streaming-networks.com>>
          > > Sent: 08/06/06 09:13:43
          > > To: "trimedia@yahoogroups.com <mailto:trimedia%40yahoogroups.com>
          > > <mailto:trimedia%40yahoogroups.com>"<trimedia@yahoogroups.com
          > <mailto:trimedia%40yahoogroups.com>
          > > <mailto:trimedia%40yahoogroups.com>>
          > > Subject: [trimedia] Conflict due to violation of restricted pointer
          > > assumption
          > > Dear All,
          > >
          > > I came across an interesting question regarding violation of "restrict
          > > assumption". Attached is an example.
          > > The answer in this case turns out to be 5 (on the simulator), could
          > > have been 6. I may as well say that the answer is undefined.
          > >
          > > Does anybody have an idea how does the DSPCPU handle the case when we
          > > try to write different values to same memory location in the same
          > > cycle. How does the hardware handle this conflict?
          > >
          > > ... Just an academic sort of query, don't have any good reason to do so.
          > >
          > >
          > > main()
          > > {
          > > int a, b;
          > > writeConflict(&a, &a);
          > > printf("%d",a);
          > > }
          > >
          > > int writeConflict(int *restrict a, int *restrict b)
          > > {
          > > *a=5; *b=6;
          > > }
          > >
          > > (* cycle 0 *)
          > > IF r1 iaddi(0x6) r0 -> r8 (* alu/Op7 *),
          > > IF r1 ijmpt r1 r2,
          > >
          > >
          > > [Message truncated. Tap Edit->Mark for Download to get remaining
          > portion.]
          > >
          > >
          >
          > [Non-text portions of this message have been removed]
          >
          > [Non-text portions of this message have been removed]
          >
          >


          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.