Dealing with FAR pointers in code library for multiple embedded platforms

Question

I'm trying to maintain a library of code, with samples, for multiple embedded platforms. I need to support the concept of "far" (non 16-bit) pointers for some function parameters.

I thought I had a good solution with defining the macro FAR to be __far on some platforms and nothing on platforms with 32-bit pointers (embedded Linux, Win32, etc.). With that macro, I could easily define pointers as somestruct_t FAR *foo.

But then I started working with Freescale processors, and their compiler requires the FAR to go between the asterisk and variable name. (somestruct_t * __far foo).

The best solution I've come up with to handle this case is to define a macro FARPTR as either __far *, * __far or just * depending on the platform. This allows for somestruct_t FARPTR foo.

Are there cleaner solutions out there? In particular, I don't like that there isn't a * visible to someone reading that code. I'm also worried that I will run into problems when it comes to function declarations. Get a load of this syntax from the Freescale compiler help:

int __far *f();          // __far function returning a pointer to int
int * __far f();         // Function returning a __far pointer to int
int __near * __far f();  // __near function returning a __far pointer to int

That last one kills me -- a qualifier inside of the return type indicates a near function?! And I've recently learned that adding the __near isn't enough to actually compile a function to near memory -- I need to wrap it in pragmas.

So, has anyone seen a nicer solution than my FARPTR macro idea?

Answer 1

The freescale processor's usage is more consistent with standard type qualifiers such as const, that placement causes it to refer to the pointer not the data being pointed to. That said, since "far data" rather than a "far pointer" would be meaningless, you'd have thought that it would not matter, but greater consistency presumably makes for a simpler compiler parser.

You could use something kludgey such as:

#if defined __SOME_ARCHITECTURE__

    #define DECLARE_FARPTR( type, identifier ) type __far * identifier

#if defined __SOME_OTHER_ARRCHITECTURE__

    #define DECLARE_FARPTR( type, identifier ) type * __far identifier

#else

    #define DECLARE_FARPTR( type, identifier )

#endif

Then your declarations would look like:

DECLARE_FARPTR( somestruct_t, foo ) ;

or in a function prototype taking a pointer parameter:

void fn( DECLARE_FARPTR( somestruct_t, foo )  ) ;

or a function returning a far pointer:

DECLARE_FARPTR( somestruct_t, fn( void ) ) ;

As you can see it quickly gets hard to read and a declarative function-like macro is generally a thing best avoided.

Answer 2

I don't have a specific better solution for you. However, having dealt with the same problem on several occasions, I recommend a review of the AUTOSAR Specification of Compiler Abstraction (PDF).

It includes a detailed approach to dealing with multiple compilers.