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.
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.
it seems to be time for the old one the '51 ain't no PC that should settle it. a footnote: this is about the '51, not about Keil. Whatever Keil does, the compiler can not change the architecture of the microcontroller Erik