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

Understanding Output Listings

I am working on a project with an 8k code space limit (Only using the internal flash of the analog devices ADuC824).

I have had some success decreasing the code size by eliminating library routines such as memmove(). And I was wondering if there is any documenation that specifies what the library routine are in the output listing file (*.m51).

Below is the list of library rountines currently used in my project. Some are obvious like (?C?COPY) and (?C?MEMCMP). If I know what the others are I may be able to restructure my code to eliminate them and save some space.

I currently have about 300 bytes of code space left and I still have some functionality to add!

Thank you.

C:\KEIL\C51\LIB\C51S.LIB (?C_STARTUP)
C:\KEIL\C51\LIB\C51S.LIB (?C?COPY)
C:\KEIL\C51\LIB\C51S.LIB (?C?CLDPTR)
C:\KEIL\C51\LIB\C51S.LIB (?C?CLDOPTR)
C:\KEIL\C51\LIB\C51S.LIB (?C?CSTPTR)
C:\KEIL\C51\LIB\C51S.LIB (?C?CSTOPTR)
C:\KEIL\C51\LIB\C51S.LIB (?C?LMUL)
C:\KEIL\C51\LIB\C51S.LIB (?C?ULDIV)
C:\KEIL\C51\LIB\C51S.LIB (?C?SLDIV)
C:\KEIL\C51\LIB\C51S.LIB (?C?LNEG)
C:\KEIL\C51\LIB\C51S.LIB (?C?SLCMP)
C:\KEIL\C51\LIB\C51S.LIB (?C?ULCMP)
C:\KEIL\C51\LIB\C51S.LIB (?C?ULSHR)
C:\KEIL\C51\LIB\C51S.LIB (?C?LLDPTR)
C:\KEIL\C51\LIB\C51S.LIB (?C?LLDCODE0)
C:\KEIL\C51\LIB\C51S.LIB (?C?LSTIDATA)
C:\KEIL\C51\LIB\C51S.LIB (?C?LSTKIDATA)
C:\KEIL\C51\LIB\C51S.LIB (?C?MEMCMP)
C:\KEIL\C51\LIB\C51S.LIB (?C_INIT)
C:\KEIL\C51\LIB\C51S.LIB (?C?LLDIDATA)
C:\KEIL\C51\LIB\C51S.LIB (?C?LLDXDATA)
C:\KEIL\C51\LIB\C51S.LIB (?C?LLDPDATA)
C:\KEIL\C51\LIB\C51S.LIB (?C?LLDCODE)

  • The whole point of a Library is that the Linker only includes those functions which are actually used; so your focus should be on optimising your own code, rather than trying to pick the Libraries apart.

    Have you read the section in the C51 manual on writing optimum code?

    Paying careful attention to where your variables are placed (DATA, XDATA, etc) can have a significant impact on code size: accessing XDATA requires more code PDATA and significantly more than DATA - so make sure your most frequently-used variables are in DATA.
    I recently had a Project where one variable was used a "key" to index all sorts of other data all over the place; simply moving this from XDATA to DATA saved over 1K of code!

    You can easily identify your most frequently-used variables with the uVision Browser: just double-click the 'Uses' column heading, and the listing will be sorted by the number of times each symbol is used.

    Unfortunately, you can't print the info from the Browser :-(
    As bemoaned here: http://www.keil.com/forum/docs/thread1260.asp

  • I see that both signed and unsigned versions of long division and long comparison library routines are being linked in. You might check your code to see if your use of these operations could be performed as either all signed or all unsigned, possibly eliminating one or two library routines. That would free up a little bit of space -- admittedly not much, but when you're in "code cramming" mode, every little bit helps.

    Regards,

    --Dan Henry

  • Thanks for the advice, but I AM optimizing my code and I don't have XDATA memory space. Identifing the library routines and restructuring my code to avoid using them has produced significant savings so far. For example, I was using memcpy() to put small strings into an output buffer. I found that it was more efficient to assign literals to each array element rather using the memcpy(). For example:

    Rather than:

       memcpy(outputBuff, "ACK", 3);
    
    I used:
       outputBuff[0] = 'A';
       outputBuff[1] = 'C';
       outputBuff[2] = 'K';
    

    This decreased the code size of my module and eliminated a four byte constant (I don't need the null at the end of strings.). In only one case did avoiding the memcpy take more code space, but it took only a very small amount compared to the amount of increased code in the
    ?C?LIBCODE segment.

    I have reduced the size of the LIBCODE segment by almost 1k so far. Most of the time my changes also reduced the size of my code.

    This has been a very interesting project so far, only 256 bytes of RAM and only 8k of code space . . . . . .