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.
Woa, so much nervious replies. Get easy on the coffee,ok? I will try to make myself clear this time. -- 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). Now, if i'm having some parsing functions, i have to use one common pool, cant define array or other variables in function (nvm that one). "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.) About "slow-inneficient-stack-approach" Excuse me, but I have only 8k Ram,and i care less about couple of ms. So i prefer the function to do some pushing,popping,calling. The general question was - how do i make it? (Wihtout reentrant) PS. Erik - [yes, there is and, amazingly enough, that is how it works. That the stack is not involved does not disable thais.] Local variables are defined in stack. No stack - no local variables.
"Excuse me, but I have only 8k Ram,and i care less about couple of ms." no you have only 248 bytes at max for stack Stack is always in IRAM on x51. So putting local vars on stack might be a bad idea. Thomas
Okay. So the only way is to define myself a pool of memory in global area , and use it from functions. Thank you.
Stack is always in IRAM on x51. Odd, the ADuC 8xx family can put the stack in XRAM.
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