Function pointer in C51

Function pointers are provided in the C language. In my opinion, an important function is to provide interfaces so that the C language can simulate an object-oriented language to provide interfaces for some functions and implement functional code isolation. This is not the case. I wrote a small program in the past few days, which was written by using C51. One of the functions is to operate the LCD screen and display menus and output results on it. In my opinion, it is better to use function pointers for these functions. For example, no matter what menu, you must display it and define a show () interface. In this way, the upper-layer code is very simple. The show () interface is called for each menu, and they are displayed by themselves. Well, the idea is good, and the result is bad. First of all, there is no problem at the syntax level of C51, and there is no error after compilation. However, some strange phenomena are found during the actual operation. For example, when a function is called, the value of the entry parameter is 100, and other values are inexplicably transferred to the function. It took a long time to solve the problem. Finally, there is no way to switch the keil to the Assembly mode. This will cause a problem. The variable address of the entry parameter and the address of a global variable are duplicated. Here, let's talk a little bit about the problem. The little thing I made uses 8031, and there are only 128 variable spaces in the slice. This also includes the space of the stack segment, therefore, I do not easily define the internal variables. In most cases, the external variables are used. Anyway, the speed of the external variables is enough for what I do. Now the question is, how can the address of the entry Parameter Variable be the same as that of other global variables? I analyzed it carefully for a long time and found that it was a fault caused by function pointers. If there is no function pointer, every function in the program has Code directly called. For example, if the initial menu is displayed, the startMenuShow () function may be called. But now it becomes a function pointer, and the code that shows the initial menu is changed to menu [START]. show (). That is to say, the compiler does not know where the startMenuShow () function is called during compilation, but does not know which function is called only during running. If there is no function pointer, the compiler can build a complete function call tree and allocate variable space based on the tree. With function pointers, the function call tree is different from the actual situation. Compiler Optimization leads to repeated variable spaces. For example, the following code is available in the C51: unsigned short c_add (unsigned char xdata a, unsigned char xdata B) {a ++; B ++; return (a + B );} void main (void) {unsigned char xdata score1, score2; unisgned short xdata total; score1 = 100; score2 = 80; total = c_add (score1, score2 );} in the code above, the two form parameters a, B and main () of the c_add () function have different real parameters score1 and score2, because in the main () function, after the c_add () function is called, the variables score1 and score2 may be called later. Therefore, the compiler does not define the four variables in the same position. However, if the main () function uses a function pointer to call the c_add () function, the compiler does not know what the function called in the main () function is. For the sake of code optimization, to save variable space, the compiler can add c_add () to the variable when it finds that the c_add () function has no direct or indirect call relationship with the main () function () the address of the variables score1 and score2 of the two form parameters a, B, and main () are defined to the same address. Because these four variables are the local variables of the function, and there is no direct call relationship between them, even if the address is repeated, it will not cause any logical problems. This definition can save the space occupied by program variables. For embedded systems, resources are generally limited, saving time. The default settings for Compiler optimization are generally relatively high. I do not recommend you adjust the optimization level for the function pointer. After all, there are still some benefits of optimization. In conclusion, my conclusion is that function pointers should be avoided whenever possible during the development of the program. If necessary, we should also avoid using form parameters and local variables, in order to avoid unexpected consequences for the program due to repeated addresses, it is very difficult to find these problems. Of course, if we don't use C51, what I know is that in embedded development, the C language used in the ARM9. there is no problem with function pointer support, my other system uses a lot of function pointers.

This article is from the "rainman" blog, please be sure to keep this source http://lancelot.blog.51cto.com/393579/224373