class member function pointers

[CaffineCoder]

the following code compiles but i goto the wrong address actually another function instead of assigned

this is just a knock up of the actually class but should be the only applicable code?

Caffeine cant help me anymore what goes on here enlighten me please respected freescale community members.

*EDIT* something of note... i am using the HC12 micro / CW 4.5

whilst debugging i found that the function func() in this case sits at 0xF2BED8 all good the address loaded into the CB variable is 0xBED8F2 (offset 0 , index -1) is this a complier error? notice that LSByte should be MSByte or does it interrupt a pointer differently to a function pointer ?

*\EDIT*

class Foo; //fwd declaration

typedef void (Foo::*Callback)(UINT16);

class Foo //declaration proper

{

public:

Callback CB;

void somefunction();

void somethingelse();

void func(UINT16);

static Foo foo;

}

Foo Foo::foo;

Foo::Foo

{

func(0); //dummy call to stop compiler "optimising" function out

}

void Foo::somefunction()

{

CB = &Foo::func(); //assign addr

}

void Foo::somethingelse()

{

this->*CB(7); //call with param ?

}

Message Edited by CaffineCoder on 2007-03-0710:07 PM

Message Edited by CaffineCoder on 2007-03-0710:16 PM

Alban Edited message following user request via abuse link

Message Edited by Alban on 2007-03-08 09:11 AM

[CaffineCoder]

More info i am using the -Ml compiler directive (large memory model) and have recompiled the applicable librarys with this directive with no good results

as far a can i tell it is FCALL's fault but how to get around it is beyond me at this time

void __far _FCALL(void) {
 __asm {
   LDY   1, SP                           ; A B C D E F    Y = B C   ; 2 bytes
   MOVW  3, SP,  1, SP            ; A D E D E F    Y = B C   ; 4 bytes
   MOVB  0, SP,  3, SP             ; A D E A E F    Y = B C   ; 4 bytes
   MOVB  5, SP,  0, SP             ; F D E A E F    Y = B C   ; 4 bytes
   STY   4, SP                           ; F D E D B C    Y = B C   ; 2 bytes
                                               ; F D E A B C              ;16 bytes
   RTC                                      ; call function pointer
 }
}

[CompilerGuru]

Hi,

right now I dont have a HC12 compiler here, so I cannot try. But note that HCS12 function pointers are using a special byte ordering, its not just big endian. Instead the byte ordering is implied by the way the HC12 CALL instuction expects the bytes to be in memory indirect calls. So function pointers start with a 16 bit offset (the low part of the address) followed by the page value. As wild guess this is because the CALL instruction takes the PAGE value in addition to the 16 bit address as a simple JSR, so maybe this way the execution of the CALL is simpler.
I think the value you see looks actually ok for a far function pointer.
In the end, I guess you should file a service request so the support can properly handle and check the case.

Anyway, I would also usually not recommend to use the large memory model especially for the HCS12/HC12's because of the huge overhead for accessing far data. (For the HCS12X, the overhead is less, but still considerable).

Daniel

[CaffineCoder]

Thanks for your reply Daniel,

I am using the MC9S12XDP512 chip and have desided on large memory model because data passing etc is easier and i am lazy, real time proformance is not an issue in the system.

cant really wait for a service request fix the deadline approaches fast any ideas on a nasty work around ? maybe an asm solution to call manually replacing FCALL?

Kind Regards

CaffineCoder

[CompilerGuru]

I only changed your sample to make it compile, tried it out on CW 4.5 but I did not see any the problems.
I could imagine that in the process of extracting the real problem you followed the wrong track with the unusual byte ordering of the far function pointers and removed too much to reproduce the bug.

Workaround? Really depends on the actual bug. Without knowing this one, well C style function pointers?

Whatever the problem you have is, I really doubt it is _FCALL, I think you are on the wrong track there.

Daniel

class Foo; //fwd declaration
typedef unsigned int UINT16;
typedef void (Foo::*Callback)(UINT16);
class Foo //declaration proper
{
public:
Foo();
Callback CB;
void somefunction();
void somethingelse();
void func(UINT16);
static Foo foo;
};
Foo Foo::foo;
Foo::Foo()
{
func(7); //dummy call to stop compiler "optimising" function out
}
void Foo::somefunction()
{
CB = &Foo::func; //assign addr
}
void Foo::somethingelse()
{
this->*CB(7); //call with param ?
}
void Foo::func(UINT16 seven)
{
  while (seven != 7) {  }// wait here if not 7   
}
void main(void) {
  /* put your own code here */
  Foo::foo.somefunction();
  Foo::foo.somethingelse();
  for(;;) {} /* wait forever */
}

[CaffineCoder]

i hate to disagree with a Guru but i am going to anyway...

after taking all the callback funtions out of the class and making the callback var static it works perfectly, so i still believe that there is a problem with class member function pointers.. i did a test with other compilers and the operated perfectly with both sets of code member function pointers and global.

maybe you didnt experience the problem because of compiler settings differences?

[CompilerGuru]

---

CaffineCoder wrote:

i hate to disagree with a Guru but i am going to anyway...

Well, do we disagree after all? My statement was that for me the bug did not show up with the code I did show. To reproduce, create a project with the wizard for the XDP512, select C++, Large memory model and past the code in the previous mail into main.cpp.
With this setup, the code behaves properly. I was using the options "-CpuHCS12X -D__NO_FLOAT__ -Ml".

after taking all the callback funtions out of the class and making the callback var static it works perfectly,

Not sure I understand what you did. Did you make the field CB a static instance, keeping it a pointer to member, or did change the type of CB to a plain C function pointer taking an additional Foo argument?
Anyway, does not really matter (for me) as this is just a workaround for you to meet the deadline. In the end, we have to isolate and fix the bug and after this changes, the bug does not show up anymore.

so i still believe that there is a problem with class member function pointers.

Yes, it looks like. Did you file a service request? I would propose to do so and provide a complete compilable sample, including the mcp, the elf file which fails and a description so the support understands what is supposed to happen, and what does happen.

i did a test with other compilers and the operated perfectly with both sets of code member function pointers and global.

maybe you didnt experience the problem because of compiler settings differences?

---

Daniel