This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Function Pointer - Look Up Table

Hello,

I'm using a 80C51 with the MX - extension in my design.
I want to build up a look up table (ROM) that contains the addresses of several functions. The address of each function must be split into high, middle and low - byte so that i can use it later as a "jump - table" in assembler.

For example:
/* some functions. */
void fA();
void fB();
void fC();

/* Look up table: */
static code LUT [3][3] = {H(fA), M(fA), L(fA), {H(fB), M(fB), L(fC),...

I've already tried some macros which i found in other posts like:

#define L_B(v) (*(((unsigned char *) (&v) + 0)))

This macro doesn't work with function - addresses but works well on common pointers.

Best regards,
Patrick

Parents
  • To do numeric manipulation on a pointer address, you first have to typecast the pointer to an unsigned integer of suitable size. Then you may use shift iperations or div/modulo to extract information.

    However, all architectures does not guarantee that you can get all information from the pointer converted to an integer.

Reply
  • To do numeric manipulation on a pointer address, you first have to typecast the pointer to an unsigned integer of suitable size. Then you may use shift iperations or div/modulo to extract information.

    However, all architectures does not guarantee that you can get all information from the pointer converted to an integer.

Children
  • function pointers in the '51 are 'architecturally impossible'

    YES, I mean 'impossible' that Keil has, by "sheer magic", managed to create that functionality should not make you jump into using it.

    There are a legion of problems using finction pointers in the (Keil) '51 overlaying will most likely fail, the code will be slow ....

    again The '51 ain't no PC

    Erik

    PS YES, it is possible to make 'something' while totally ignoring the underlying arachitecture, but working that way the 'something' will be grossly inefficient and, most likely, eventually, develop timing problems.