• State Not Answered
  • Locked Locked
  • Replies 26 replies
  • Subscribers 22 subscribers
  • Views 4370 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Compiler fault? (or am I missing something?)

Paul Blackmore

Using the latest Keil C compiler (V7.00)
Executing on an Infineon XC161CJ-16F
This code appears to produce the wrong result.

At the "if" statement I expect v1 to equal v3 and for the main function to return 0 (I don't actually want to use the return value, its just a mock up piece of code). However, at the "if" statement, the value of v1 is 0x1234 and the value of v3 is 0xB1234.

Can anyone explain why?

typedef unsigned long ULONG;
typedef unsigned short USHORT;
typedef BYTE * POINTER;

POINTER v1,v2,v3,v4;
ULONG temp_ptr;
int
main(void)
{
  v1 = (POINTER)0;
  v2 = (POINTER)0x0B1234;
  v1 += (ULONG)v2;        // This assigns 0x1234 to v1, I think it should assign 0xB1234

  v3 = (POINTER)0;
  v4 = (POINTER)0x0B1234;
  temp_ptr = (ULONG)v3;
  v3 = temp_ptr+v4;      // This statement assigns 0xB1234 to v3 correctly.

  if ( v1!=v3 )
    return -1;
  else
    return 0;
}

Parents
  • 0 in reply to ImPer Westermark

    @Per Westermark

    The standard doesn't claim that it is valid to typecast between pointer and integer or reverse. But 0 is a null pointer.

    I know that, but it is necessary sometimes in embedded systems.

    @Per Westermark

    So whenever you feel like typecasting between integer and pointer you need to have target-specific knowledge to understand if it is valid or not and exactly what the result will be.

    I agree I need to know the target architecture. That's the whole point of my question.

    What exactly is the compiler doing in the situation where the value is not computed as I expect it to be. What interaction between the XC161's segmented addressing and the compiler's casting of POINTER to ULONG is impacting unexpectedly on the computation?

    If anyone can answer that, it will go a long way to helping me understand the target hardware just that little bit better.

    I know I can solve it using various workarounds, if all I wanted to do was to solve the immediate problem and move on then I wouldn't have even bothered posting the question. I have a desire/need to learn what is going on under the hood.

    Regards
    Paul

Reply
  • 0 in reply to ImPer Westermark

    @Per Westermark

    The standard doesn't claim that it is valid to typecast between pointer and integer or reverse. But 0 is a null pointer.

    I know that, but it is necessary sometimes in embedded systems.

    @Per Westermark

    So whenever you feel like typecasting between integer and pointer you need to have target-specific knowledge to understand if it is valid or not and exactly what the result will be.

    I agree I need to know the target architecture. That's the whole point of my question.

    What exactly is the compiler doing in the situation where the value is not computed as I expect it to be. What interaction between the XC161's segmented addressing and the compiler's casting of POINTER to ULONG is impacting unexpectedly on the computation?

    If anyone can answer that, it will go a long way to helping me understand the target hardware just that little bit better.

    I know I can solve it using various workarounds, if all I wanted to do was to solve the immediate problem and move on then I wouldn't have even bothered posting the question. I have a desire/need to learn what is going on under the hood.

    Regards
    Paul

Children