I created a library fuction having two fuction inside 1) Loop1() 2) Loop2() when i will call the only one fucnction still the copiler will add the code for both, below i am writing the content of the library file
#pragma SAVE #pragma REGPARMS extern void Loop1(void); extern void Loop2(void); #pragma RESTORE
void Loop1() { unsigned int i=0; while(i) { i--; }
}
void Loop2() { unsigned char i=0; while(i) { i--; } how can i avoid this problem
void main() { Loop1(); Loop2(); while(1);
http://www.keil.com/support/docs/2182.htm
Jon
Hi Jon If I am using Flaoting point division compiler automatically include the C51FPL,is there any way to do the library file which will be called if and if the fuctions related to that library is called.
is there any way to do the library file which will be called if and if the fuctions related to that library is called.
did you read the link Jon posted?
the answer is there
Erik
It means if i am having 10 different functions i have to create 10 different library right?
maybe, that depends on what you mean by "different library"
you need to generate 10 different modules (source files) but they can all go into the same library
here is a commandline example for generating a library with several modules
if not exist amk.lib goto usliex del amk.lib :usliex c:\tools\keil\c51\bin\lib51 c amk.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a MKmain.obj to amk.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a MKutil.obj to amk.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a MKj1708.obj to amk.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a MKkbpr.obj to amk.lib >..\trash\trashbin
if you insist on doing it in the so called IDE, you will need to wait for someone else, I can not use that limited a tool.
No. It means you will have 10 different source files. All of the object modules (there will be 10 of them) generated by the compiler for the source files will be included in the library. This is what the knowledgebase article says.
Version 8 of the C51 tools includes a lovely new LX51 linker option, REMOVEUNUSED, to remove "dead" (uncalled) code. This helps mitigate this problem to a large extent. You no longer have to break up every .c file into one file per function.
We have run into occasional bugs with this feature when the linker removes some but not all of the dead code, and we get "unresolved external" type warnings. I think this has something to do with inter-bank calls that turn out to be dead code, but we haven't really narrowed it down yet.
Yes i got it,and created a library file having the multiple object files
"Version 8 of the C51 tools includes a lovely new LX51 linker option, REMOVEUNUSED, to remove "dead" (uncalled) code. This helps mitigate this problem to a large extent."
Err... doesn't that defeat the entire object of a Library?
doesn't that defeat the entire object of a Library
Not in my mind.
It shouldn't be necessary at all, if the tools could manage to avoid pulling unneeded code out of the library in the first place. But, the Keil tools insist on taking entire segments (.c files) as a whole, even if you only need one routine. So, you can follow up with REMOVEUNUSED to trim the code back closer to what it should have been.
The only way to get the Keil tools to behave properly is to put each function in its own .c file (whether you're going to put the .objs in a library or not). This is undesirable for a number of reasons: it's more work, it breaks up the modularity of your program for no good reason, and it inevitably exposes much more to the global name space than if you can keep related code together.
The purpose of a library is to bundle a bunch of OBJs together so that they can be handled as a unit. Many programs might link to the same library, and use various overlapping fractions of it. REMOVEUNUSED doesn't change this purpose, so I wouldn't say it "defeats the purposes" of a library. It just enhances the ability of the linker to trim down the object code without requiring a lot of manual intervention from the programmer.
Not just Keil
It is common behaivior for the Linker to pull objects from the library. Anything above and beyond means the linker is not just resolving addresses. It needs alot more smarts. i.e is that unused, or called via pointer.