This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

About Library file

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);

}

Parents Reply Children
  • 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.

    Erik

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

    Jon

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