Convert __pptr pointer to far pointer in compile time

[Deedah]

Hi,

Using S12XDP512:

I am creating a table of FLASH ranges across which to calculate CRC.  I'd like to enter in the logical paged addresses (__pptr pointer) into the C file (see below) instead of the global address (far pointer)- primarily because it takes an extra step to convert from what's seen in the PRM linker file to the global address.

The issue I had with this is that casting a __pptr to far pointer seemed to only work at run time....

So, my attempt at, say,

void * far farptr = (void * far) ( (void * __pptr)0xFEFFFF; )  //extra parenthesis to be explicit

would result in farptr being initialized with 0xFEFFFF.

My intermediate solution was to store all the pointer values as __pptr and then at startup I run a cast of all of them:

void * __pptr pageptr = (void * __pptr)0xFEFFFF;
void * far farptr;

int main() {
    farptr = (void * far)pageptr;
}

But I don't want to use up memory for this extra table unnecessarily.  I'd like the values to be const somewhere and not worry about doing this at runtime.  Can anyone comment on how I can convert these pointers at compile time?

Thank you,

Dave

[kef]

What about address conversion macro?

#define PPTR2FAR(x) ((void * far)(0x400000 | ((x >> 16) * 0x4000) | (x & 0x3FFF)))

No problem using it at compile time.

void * const far farptr = PPTR2FAR(0xFEBFFF);   //extra parenthesis to be explicit

BTW, 0xFEFFFF is illegal PPAGE logical address, offset is out of PPAGE window 0x8000..0xBFFF.

[Deedah]

Oh, thanks, makes total sense. 

On a related note:

I'm trying to increment far pointers to do said checksums and notice that it only increments the lower word, not the GPAGE portion.  My quick fix is to cast to unsigned long and back, but longer term I plan to write something in assembler to do it without that unhappiness.  Any idea if this is expected/documented behavior?

Thanks,

Dave

[CrasyCat · Accepted solution]

Hello

This is an expected behavior.

The S12X instruction set performs all address calculations on 16 bit only, it does not propagate overflows into the page.

CrasyCat