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; }
I don't use your C166 compiler, so I can't really give good answers about it. But does your compiler - at least with the memory model you are using - support huge pointer arithmetic?
Quite a number of compilers having pointers larger than 64kB requires a specific memory model or a specific keyword for the pointer to allow arithmetic to produce normalized pointers and/or support 32-bit arithmetic.
By the way - exactly why do you play with this kind of arithmetic? It isn't really meaningful in a real program unless you do have an object that is larger than 64kB - and in that case, you don't need any type cast from pointer to integer since the offset was an integer in the first place. The closest a "normal" program would get would be to have one pointer to a start of an object or memory region and another pointer to the first byte after the object - or to the next memory region. And then trying to compute the distance by subtracting the values of the two pointers.
@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