I am using CW 5.0 for S12X with a S12XE384
Far pointer variable defined as:
static unsigned int* __far adr;
In this loop:
while(adr < segEnd)
{
cs += *adr;
adr++;
}
The generated code is:
0072 fe0000 LDX adr:1 0075 f60000 LDAB adr 0078 5b10 STAB 16 007a 18ec31 GLDD 2,X+ 007d f30000 ADDD cs 0080 7c0000 STD cs 0083 7e0000 STX adr:1 008d 0705 BSR *+7 ;abs = 0094 008f 22e1 BHI *-29 ;abs = 0072 // other code 0094 fe0000 LDX adr:1 0097 f60000 LDAB adr 009a fd0000 LDY segEnd:1 009d b60000 LDAA segEnd 00a0 060000 JMP _FPCMP
The generated code is not incrementing the high order byte of the far address.
Is this a compiler bug?
As a work-around, when I change the type of adr to be unsigned long (and add the apropriate type casts), the generated code does increment the high order portion of the address.
Solved! Go to Solution.
It is normal. Try replacing __far with __ptr24. __far pointer math is faster, but G-page part of it isn't updated. This is OK for project wizard default PRM files, where no segment is crossing G-page boundary.
It is normal. Try replacing __far with __ptr24. __far pointer math is faster, but G-page part of it isn't updated. This is OK for project wizard default PRM files, where no segment is crossing G-page boundary.
kef wrote:It is normal. Try replacing __far with __ptr24. __far pointer math is faster, but G-page part of it isn't updated. This is OK for project wizard default PRM files, where no segment is crossing G-page boundary.
Ah. That explains why I inherited broken code. It wasn't actually broken.
Initially, our PRM file created descrete segments. However, due to a bug in our customer's Service Programming Tool, we have to deliver a contiguous HEX file. Since both the SPT and the tool that generates that data file from that HEX file, checks/inserts a checksum based on the entire contents, we coded our ROM check to do likewise.
So, when we added the FILL 0xFF to our segment definitions to create one contiguous load image, the segment table sent to our boot loader only had a single entry - for the entire load image. Since we coded our ROM check to use that table, that "broke" the __far pointer.