Hi:
I want to build an array that contain the pointer of some function in our program.
a simulated example is as below
//claim two function int x(void); int y (void); main() { int *(p)(void)[2]={x,y} }
When I compling, such error message appeared" error , an array of function" Dose keil support the array that contain the poiint of the function?
why I want to do this? There is an array while the first element is about the total amounts of the function to be execute, and the subsequent element indicate the corrponding function which will be execute. For example:
int array-A[3]={2,0,1}; //this mean that there is 2 functions(function_0 and function_1) will be executed.
Because of this, I want to build an extra array thant contain the pointer of the function such as below array-B={function_0_pointer,function_1_pointer};
According to the element in array-B, I will execute the corresponding function directly.
Is this idea can be supported?
Thanks for your replying!
Jason.Liu
Yes, tables of function pointers can be supported - but you need to be very sure that you fully understand all the issues.
Please take time to study the large amount of information already available on the subject:
Application Note 129:Function Pointers in C51 http://www.keil.com/appnotes/docs/apnt_129.asp
www.keil.com/.../search.asp
also search the forum for previous discussions...
You didn't say why you want to do this; you said what you are doing (or trying to do) - but not why you want to do it.
If you say what you're actually trying to achieve here, people may be able to suggest whether your approach is appropriate, and/or suggest alternatives - in particular, alternatives that are more suited to an 8051...
An 8051 is not well-suited to this, so another important question is why you are trying to do it on an 8051...?
I think a switch statement may be better here. Or another processor.
'When I compling, such error message appeared" error , an array of function"'
You have to declare it properly:
int (*p[2])(void)={x,y};
Yes, of course: before you can use function pointers at all on any platform, you have to get the basic syntax right.
But, on the 8051 in particular, there are additional specific issues that you must also understand.
Such as: The 8051 chips have lousy stack support and the 8051 compilers hates to try to generate code if they both have to fight with the stack issues and with function pointers. A function pointer means that you are treating function calls as variables. And that makes it almost impossible for the compiler to keep track of what parts of the code that may call the functions.
Do think about dropping function pointers, or switch to a processor with a full general-purpose stack implementation. Talking about Keil, I would suggest an ARM.
I just want to executed the different function corresponding to different parameter. As Per Westermark said, the switch-case structure can aslo be used.
But I think call the function directly by the adrress in the array is more effective and can save the code space.
This is why I want to do this.
Thanks
You may _think_ that it will save code space, but only because you are ignoring the problems the compiler will get into.
The compiler will fail to perform a call-tree analysis, so it will not be able to figure out which functions that may share the same global RAM for parameters and local variables.
So a small reduction in code size will cost you a significant loss of RAM - and RAM is normally the more critical parameter. Also remember that with the internal RAM is not enough, your program must make use of XDATA which does affect your code size.
So you may end up with a slightly smaller function call, but intead pay several times as much in other parts of your program.
In this case, I think your function pointer arrays are a form of premature optimization - it felt like an optimization but one that may hurt way more than any gain.
It is of course your choice, if you want to go ahead.
"I think call the function directly (sic) by the adrress in the array is more effective and can save the code space."
But, if you call it via an address from an array, you are not calling it directly at all, are you? You are calling it indirectly!
An indirect call is (almost?) bound to use more code space in any processor - since additional code is required to locate and read the required array element before the function can be called!
The specific case of an 8051 is worse, because the 8051 does not have any instruction that calls a function indirectly!
And that's before you get into all the other C51-specific function-pointer issues already mentioned...
Per, Andy, As you know I don't work with a C51. I'm curious: Is there sometimes a justification to use function pointer? Does it sometimes pay-off?
"I'm curious: Is there sometimes a justification to use function pointer? Does it sometimes pay-off?"
Sorry to butt in but I can give an answer to that.
Yes - But with the usual reason - When the situation requires it.
For example, a while ago I had the misfortune of being required to port an XML parser to an 8051 architecture. The source code relied quite heavily on function pointers, so I took the decision to use them and reduce the need for a lot of development time rather than rewrite the code in a lot of places to eliminate them.
The port was relatively straightforward, the code was reasonably close to the original and (thankfully) the customer was happy with the result :)
Are you asking in general if there is ever a justification to use function pointers, or just if it ever pays off in C51?
yes, of course there are many general cases where function pointers provide an ideal solution; some that spring immediately to mind are: Table-driven state machines; Table-driven user-interface menus; API call-backs.
Provided all the inplications are fully understood, and all the necessary precautions are taken, function pointers can be perfectly usable in C51.
But I think the OP's notion here that they give some inherent code size reduction is completely wrong?