• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 22 subscribers
  • Views 3517 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

David Herr

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)

Parents
  • 0 in reply to Andrew Neil

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

Reply
  • 0 in reply to Andrew Neil

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

Children
No data