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.
"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.