• 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
    But does your compiler - at least with the memory model you are using - support huge pointer arithmetic?

    Yes.

    @Per Westermark
    By the way - exactly why do you play with this kind of arithmetic?

    It is used in the implementation of relocatable, self-referencing data structures. The 64KB data structure is initially compiled on a PC based on a large number of configuration files.

    The PC based compilation includes setting "pointers" in the data structure to offsets within the data structure. Those "pointers" contain only ULONG values since the absolute memory location of the data structure is not known yet.

    I put "pointers" in quotes above because they are not really pointers, at this stage they are only ULONG offsets from the start of the data structure.

    When the software executes on the XC161, the data structure is loaded from flash into one of multiple possible RAM locations. Those locations are by necessity, on 64KB boundaries.

    A small routine scans through the data structure, adding the absolute RAM location of the data structure to the ULONG offsets in the data structure. That produces absolute pointers that are then used by the code without having to constantly re-compute the offset from the start of the structure.

    The reason it was done this way was for efficiency in both code space and execution time.

    Regards
    Paul

Reply
  • 0 in reply to ImPer Westermark

    @Per Westermark
    But does your compiler - at least with the memory model you are using - support huge pointer arithmetic?

    Yes.

    @Per Westermark
    By the way - exactly why do you play with this kind of arithmetic?

    It is used in the implementation of relocatable, self-referencing data structures. The 64KB data structure is initially compiled on a PC based on a large number of configuration files.

    The PC based compilation includes setting "pointers" in the data structure to offsets within the data structure. Those "pointers" contain only ULONG values since the absolute memory location of the data structure is not known yet.

    I put "pointers" in quotes above because they are not really pointers, at this stage they are only ULONG offsets from the start of the data structure.

    When the software executes on the XC161, the data structure is loaded from flash into one of multiple possible RAM locations. Those locations are by necessity, on 64KB boundaries.

    A small routine scans through the data structure, adding the absolute RAM location of the data structure to the ULONG offsets in the data structure. That produces absolute pointers that are then used by the code without having to constantly re-compute the offset from the start of the structure.

    The reason it was done this way was for efficiency in both code space and execution time.

    Regards
    Paul

Children
No data