As I can see, the keil compiler doesnt use regular stack for functions, and all the local variables inside functions are mapped in global memory. Is there a way, to make it behaive like a normal program should? I.E - create a local variables in ram,and destroy them, when the function ends? Thank you.
When the function is called,it should create variables to use. It should use some pool ,and release it,after it is done (unless it's static variable,but i'm not talking about it). Have you read the chapters about memory overlaying in the compiler and linker docs ? Have you understood what exactly memory overlaying means and why it is the better way of creating local variables on a '51 ? The compiler does exactly what you describe above, _without_ using a stack. If you don't do things you shouldn't do anyway on a '51 (function pointers) or really need reentrancy, there is no reason to resort to using a stack. Local variables are defined in stack. No stack - no local variables. It is completely irrelevant _where_ local variables are. They are defined by exiting only within the scope of one function. Whether this is done by using a stack or using memory overlaying is of no concern. "reentrant" key does make the function to do what i intend, but the assembly is so ugly, and it immediately involves so much bugs with optimization, that i have to disable it (optim.) Using a stack leads to ugly assembly code on the '51 architecture. That's why the standard behavior of the C51 compiler is to use memory overlaying instead, a much, much more efficient and much, much less ugly approach.
The compiler does exactly what you describe above, _without_ using a stack. Why, then, when the code is compiled, and compiler shows me the sum of all memory used, all the local variables are counted as global? And if it exceeds 8k, wont let me compile (makes sense)
Why, then, when the code is compiled, and compiler shows me the sum of all memory used, all the local variables are counted as global? Did you enable memory overlaying as an optimization ? Are you using things that keep the linker from building a complete calling tree (function pointers) ? Also, the compiler does not do memory overlaying (it cannot, as it works on single files). What does the linker output say ? If overlaying is enabled and the linker can build a complete calling tree, and the memory used for the local variables and parameters is still equal to their sum, then no overlaying is possible and this is the amount of memory that is necessary, no matter whether you use a stack or overlaying. If you used a stack instead and allocated less memory than is used with the above method, you're asking for a stack overflow.
Yes. I am using a state machine, thus having function pointers. But the specifig function i am using , is not called by pointer. Or one function pointer will ruin the whole optimization?
Or one function pointer will ruin the whole optimization? Yes ! Because neither the compiler nor the linker will ever be able to unambiguosly figure out which function the pointer will point to at a certain point in the program, and therefore the linker cannot build a calling tree. Please re-read the chapters about memory overlaying and function pointers. Use a switch/case instead. Or, build the calling tree yourself, though that is probably the more complicated solution.
Thank you, Christoph, for your help. Now i know the problem, i will try to handle it. Thank you again.
As a matter of fact,here lies the solution http://www.keil.com/support/man/docs/bl51/bl51_ol_fp.htm I will try this. Thanx again :)
"I am using a state machine, thus having function pointers." That is a non-sequitur. A state machine does not require functions pointers. Using function pointers is one way of implementing a state machine, but is certainly not the only way! eg, you could use switch statements...
" ... one function pointer will ruin the whole optimization ... Because neither the compiler nor the linker will ever be able to unambiguosly figure out which function the pointer will point to at a certain point in the program, and therefore the linker cannot build a calling tree." Not necessarily. There is an Application Note that describes the necessary steps for safe use of function pointers in C51: http://www.keil.com/appnotes/docs/apnt_129.asp Also, search the knowledgebas for "function pointer"
Not necessarily. Quite necessarily. The Appnote mentions that. The linker cannot figure out the calling tree on its own, it has to be told (through directives) what the calling relations are. Still ... function pointers are messy. They make the program very difficult to understand for anyone trying to maintain the program. They cause even more issues on a '51. Only use them if they are the only way to do what you're trying to do. (and I doubt the latter applies to a lot of things).
The Application Note describes a way to use tables of function pointers without having to resort to manual OVERLAY directives: "The C51 Compiler and BL51 Linker work in combination to make overlaying the variable space of function easy when you use tables of function pointers. However, you must declare the pointer tables appropriately. If you do this, you can avoid using the OVERLAY directive." (my emphasis). Typically, function pointers used to implement a state machine would be used in tables. "Still ... function pointers are messy. They make the program very difficult to understand for anyone trying to maintain the program." I disagree. A large state machine implemented with switch states can be very cumbersome to maintain; function pointers can be very beneficial here! Whether that makes them a good idea on an 8051, though, remains open to question...
based on your posts above I gather that some idiot at some institution of lower learning told you that C is device independent. That is TOTAL AND UTTERLY BULLSHIT C will be implemented by any decent compiler the best way the underlying processors architecture allow If you have taken the decision not to understand the difference between a PC and a '51, good luck getting anywhere. Erik
2erik: amazing. Post with no information whatsoever. I would like to see the end of debate between Andy and Christoph, though.
C is device independent. That is TOTAL AND UTTERLY BULLSHIT Is that not 'information'? If he actually believe that C is device independent, then this could very well be the best information in the whole thread Erik
"I would like to see the end of debate between Andy and Christoph, though." Meanwhile, you should read the App Note for yourself and decide what, if any, of it applies to and/or helps in your specific circumstances...
Ok, from the appnote: * If you use function pointers, you must adjust the calling tree manually. Exception: * If you only use an array of constant function pointers stored in code memory (which is pretty much a fancy way of implementing a jump table), the compiler and linker are usually smart enough to figure things out on their own. However, I think there's plenty of ways that will mess up the exception. Some clever person might, for example, modify the array of function pointers in code memory and still expect their code to work properly. Or they use the array in several different functions all over the place and still expect the compiler/linker to be able to follow their train of thought.