when i use preprocessor #if 0 ... #endif to cross out a bunch of sentences, then after building the target. I noticed the "data" memory usage increased, why? There is no error in the result.
The compiler is able to overlay data used by different functions based on analysis of the call tree. If the compiler can prove that two functions are in different paths down the call tree, then it can reuse that memory for both functions. If you comment out a call to a function, you remove it from the call tree. If the function continues to exist in the code, despite not being called, then the compiler has no choice but to assume the function is the root of a new call tree (as though it were an interrupt handler). Since this is a new tree, its memory cannot be shared with any other function. If the function had overlaid memory, after you comment out the call it will no longer share that memory, and total usage will increase. One workaround is to #if out the body of the function as well as its call. Another is to come up with a coding trick that will keep the function in the call tree, yet not actually call it, e.g. "if (0) MyFunc();" Another is to put every single function in a different .c file, so you can modify the project file not to link it in. One of my top wishes for the Keil toolset is for them to implement dead code elimination in the linker so that it can find these uncalled functions, remove the code, and, importantly, not allocate the memory for the dead functions in the overlay analysis.
Another is to put every single function in a different .c file, so you can modify the project file not to link it in. And the winner is .... put the functions in a library, they will only be included if called. Erik
"One of my top wishes for the Keil toolset is for them to implement dead code elimination in the linker so that it can find these uncalled functions, remove the code, and, importantly, not allocate the memory for the dead functions in the overlay analysis." Would this help? http://www.keil.com/support/man/docs/lx51/lx51_removeunused.htm
What version of LX51 is required? Also note that it's LX51 only - not BL51. (which, I think, means it won't be in the free Eval download?)
"What version of LX51 is required?" I don't know, I just remembered having noticed the addition sometime recently. Check out the release notes if you're interested. "Also note that it's LX51 only - not BL51." I also seem to remember that Drew uses LX51.
"I don't know, I just remembered having noticed the addition sometime recently." I seem to remember having looked for and not found it a while back - hence assumed it must be recent. (it certainly isn't in the 2001 PDF version of the Manual). "Check out the release notes if you're interested." I did, but couldn't see it mentioned. :-(
"I did, but couldn't see it mentioned. :-(" Look harder!
"Look harder!" No, it's just a question of looking in the right place. Foolishly, I just went to the C51 products page, http://www.keil.com/c51/v7_faq.htm and looked at the release notes there: http://www.keil.com/update/_docs/releasenotes/c51v700.htm - not a mention. Just now, I tried looking at the Product Updates page - and there it is, as a new feature in C51 v7.50a: http://www.keil.com/update/whatsnew.asp?p=C51&v=7.50a So this really is a brand-new, hot-off-the-press, latest release feature! Unfortunately, the release notes are not dated, so we still don't know exactly how "new" it really is... :-(
"Unfortunately, the release notes are not dated, so we still don't know exactly how "new" it really is... :-(" Found this in my Keil Information Update e-mail of November 2004: "C51 Version 7.50a corrects a problem that was introduced in V7.50 with LX51 Linker Code Packing and the REMOVEUNUSED directive."
"Found this in my Keil Information Update e-mail of November 2004" You actually found a link to the release notes for all of the version 7.x toolchain. If you had scrolled a little further down you would have noticed that this feature was added in v7.50 and then corrected in 7.50a. You did follow that link to check the new features and bug fixes when you received your newsletter in November 2004, didn't you?
Would [REMOVEUNUSED] help? I haven't tried it personally. But according to my co-workers that have, it doesn't really do what I hoped. That is, the call tree still explodes unless we manually take out unused functions. But maybe they're not using the new feature quite right. I'll have to investigate.
"That is, the call tree still explodes unless we manually take out unused functions." I suppose what's really required is a compiler directive such as: #pragma IDONTUSEFUNCTIONPOINTERS
That is, the call tree still explodes unless we manually take out unused functions. That may have been caused by the linker not being able to tell that these were unused. If, as the other reply hinted, function pointers are involved in any way, it's provably impossible to do call tree analysis in the general case, i.e. the linker has to drop the ball at some point. In an (admittedly minimalistic) example I just tried, it worked just fine: the un-called function and its data segment show up in the map file only in a new segment list titled "REMOVED SEGMENTS": they don't appear in the call tree, nor in the final program.