| Details | Message |
|---|
Read-Only Author Shrinath Eswarahally Posted 9-Jun-2004 23:45 GMT Toolset C51 |  Problem with Compiler/linker Generating code for indirect function pointers Shrinath Eswarahally void sys_startup_init(BOOL8 shutdown) { // // Check for operating mode // if (!shutdown) { // setup MMU shutdown = (*isys_startup_mmu_init)(shutdown);
.... }
// Shutdown if mode is not normal .... }
The sys_startup_init function is entered from assembly code.
The code shutdown = (*isys_startup_mmu_init)(shutdown); function pointer is where the code execution is incorrect.
Changing the function to : void sys_startup_mmu_init(void)
results in the correct code being executed. However is not possible to change all the indirect function calls in this manner, so this is not a feasible solution.
C compiler version: 7.07h |
|
Read-Only Author Andrew Neil Posted 10-Jun-2004 06:44 GMT Toolset C51 |  RE: Problem with Compiler/linker Generating code for indirect function pointers Andrew Neil "The code shutdown = (*isys_startup_mmu_init)(shutdown); function pointer is where the code execution is incorrect."
In what way is it "incorrect?"
How have you declared isys_startup_mmu_init?
C51 has particular issues with function pointers - have you read the articles in the knowledgebase? (search for "function pointer")
"not possible to change all the indirect function calls in this manner"
Why not? Why do you have to call these functions indirectly? |
|
Read-Only Author Neil Kurzman Posted 10-Jun-2004 16:07 GMT Toolset C51 |  RE: Problem with Compiler/linker Generating code for indirect function pointers Neil Kurzman indirect called functions may have to be declaced "reeentrant". There is a size and speed penalty to be paid for using function pointers. |
|
Read-Only Author Andrew Neil Posted 10-Jun-2004 16:36 GMT Toolset C51 |  RE: Problem with Compiler/linker Generating code for indirect function pointers Andrew Neil "indirect called functions may have to be declaced 'reeentrant'."
Not really.
The problem is that the Linker may not be able to work out the call tree, and then cannot do the overlaying. The correct way to fix this is to give the Linker the information it needs.
You need to read Application Note 129: Function Pointers in C51 http://www.keil.com/appnotes/docs/apnt_129.asp
Also see this knowledgebas article: http://www.keil.com/support/docs/210.htm
And refer to the description of the OVERLAY control in the Linker Manual |
|
Read-Only Author Andrew Neil Posted 10-Jun-2004 16:38 GMT Toolset C51 |  RE: Problem with Compiler/linker Generating code for indirect function pointers Andrew Neil "There is a size and speed penalty to be paid for using function pointers."
But only very, very small if you fix it properly via the Linker (as described above), rather than bodging the source code (with 'reentrant', etc)! |
|
Read-Only Author Neil Kurzman Posted 10-Jun-2004 18:23 GMT Toolset C51 |  RE: Problem with Compiler/linker Generating code for indirect function pointers Neil Kurzman That would be true if the orinional programmer, on my project did not decide that he wanted floats and function pointers, then it would not fit so lets add bank switching. My program pass to many parameters, so I need reentrant. My point was it is an 8051.
Do not use C features that the 8051 does not like unless there is a real need. I my case fixed point math and flags to choose functions would have made a smaller, faster, cleaner program. |
|
Read-Only Author Andrew Neil Posted 10-Jun-2004 20:21 GMT Toolset C51 |  RE: Problem with Compiler/linker Generating code for indirect function pointers Andrew Neil "My program pass to many parameters, so I need reentrant"
That shouldn't matter.
C51 has no specific difficulty with long parameter lists - it passes excess parameters using fixed memory locations. There is no problem provided the Linker can either work out the call tree itself, or you provide the information manually |
|
Read-Only Author Neil Kurzman Posted 10-Jun-2004 22:32 GMT Toolset C51 |  RE: Problem with Compiler/linker Generating code for indirect function pointers Neil Kurzman I did not say it would not work, it does. by 2 floats and an int requires reentrant (far as I know). The origional programmer did not ask do I need to do this. You can not write for the 51' like "memory is cheap". reentrant do not get overlaid. In my case I have several things done it the program that make it bigger and slower. And none where required. It was done like it was a PC. I just wanted to point out the poster that he may want be sure he needs to use function pointers |
|
Read-Only Author Andy Neil Posted 11-Jun-2004 02:26 GMT Toolset C51 |  RE: Problem with Compiler/linker Generating code for indirect function pointers Andy Neil "2 floats and an int requires reentrant"
No, it doesn't. The following (admittedly trivial) function compiles OK without any need for reentrant:
void func( float f1, float f2, float f3, float f4, int i)
{
volatile int local_int;
volatile int local_float;
local_float = f1;
local_float = f2;
local_float = f3;
local_float = f4;
local_int = i;
}"...none were required. It was done like it was a PC."
Yes, that's exactly how I found out all this stuff! Initially, someone else started the port and used reentrant to get around the function-pointer problem - but it is not necessary. By supplying the appropriate Linker options, the Linker is able to correctly overlay these functions.
You can (probably) reduce the overhead in your code by abandonging reentrant and using the appropriate Linker controls? |
|
Read-Only Author Neil Kurzman Posted 11-Jun-2004 16:26 GMT Toolset C51 |  RE: Problem with Compiler/linker Generating code for indirect function pointers Neil Kurzman Thanks I will keep it in mind. But, in my case 8 of 10 the function calls were set at the begining and do not change. I assume they were for future flexibility that was never needed. |
|