topic Re: __far increments only low order 16 bits in CodeWarrior for MCU

__far increments only low order 16 bits

rlw — Thu, 29 Oct 2020 08:57:43 GMT

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.

Re: __far increments only low order 16 bits

kef — Thu, 28 Jul 2011 00:02:03 GMT

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.

Re: __far increments only low order 16 bits

rlw — Thu, 28 Jul 2011 00:42:51 GMT

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.