Question

I realize that far is compiler specific, but my expectation is that the placement of the far specifier should make sense to those who really understand pointers.

So, I have two applications that share the processor’s entire memory space.

App A needs to call function foo that exists in app B.

I know the memory location of function foo.

So this should work, in app A:

typedef int (* __far MYFP)(int input);  void somefunc(void) {    int returnvalue;    MYFP foo;     foo = (MYFP) 0xFFFFFA;     returnvalue = foo(39); } 

• Is the __far in the right spot in the typedef?
• Do I need to add __far to the (MYFP) cast?
• Some information suggests that the call to foo doesn’t need to be dereferenced, what is your experience?

• What else about this looks incorrect, or might I try to accomplish this?

• Is there a better way to do this?

Edit:

This is on an embedded device (Freescale S12XEQ device) using Code Warrior. It’s a 16 bit device with 24 bit memory space, so yes, it is segmented/banked.

-Adam

Answer 1

Is the __far in the right spot in the typedef?

[Edit, in response to ChrisN’s comment — thanks]

This is a compiler-dependent feature, since it is not part of ANSI C. According to the compiler manual <http://www.freescale.com/files/soft_dev_tools/doc/ref_manual/CW_Compiler_HC12_RM.pdf>, chapter 8, you have it placed correctly. In other compilers, you may need to reverse the order. This should be pretty easy to figure out, though, since exactly one of the two options will compile with any given compiler.

Do I need to add __far to the (MYFP) cast?

Nope, it’s part of the type.

Some information suggests that the call to foo doesn’t need to be dereferenced, what is your experience?

Function pointers can be optionally dereferenced in C. The following lines are both valid do the exact same thing:

foo = (MYFP)0xFFFFFA; returnvalue = foo(39);  // 1 returnvalue = (*foo)(39);  // 2 

What else about this looks incorrect, or might I try to accomplish this?

You’ve done it exactly correctly.