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

code reduce

Hi All

I'm writing a software for 8 bit architecture using uvision 2. But when I try to compile my project using uvision2 it gives the following error

*** ERROR L107: ADDRESS SPACE OVERFLOW
.
.
.
Program Size: data=171.7 xdata=15942 code=65617
 

my target system has only 64KB code space it seems overflow.

How can I reduce code size for this application.

I'm using Code Optimisation Level 9 from uvision2.

any idea

  • "any idea"

    LX51 code packing gives significant reductions in code size. I think it only comes with the more expensive packages, but if you've got it, use it.

  • There is a whole chapter in the C51 manual on writing optimum code.

    It has been discussed here many times - do a 'Search'
    See also http://www.8052.com/forum/read.phtml?id=71821

    http://www.keil.com/forum/docs/thread5234.asp

  • the post (right now next to yours) "Understand The 8051's Capabilities and C51 Assembly Output." basically show why so many experience "code" overflows. If you (I am not saying that you are - not a flame) are applying "PC techniques" a bit of recode with forethought will dramatically reduce your code size. Even if you have coded with the '51 in mind, you can often find places where you can change a small thing and achieve code size savings. The optimizer will give you size or speed, manual codeing with forethought gives you both.

    Erik

  • You have an overflow in the data space as well as the code size.

    If you have any routines in your source that are not called, you need to get them out by one means or another. The Keil linker cannot break up a single segment (which corresponds to a .c file) and remove the unused routines. This is not just a problem for code space, but for the compile-time stack overlay analysis as well.

    If you're porting this software from another architecture, you may need to work on the code somewhat to make it more 8-bit-friendly.

  • "You have an overflow in the data space as well as the code size."

    The linker, or at least the version I use, doesn't make a distinction between data and idata in its memory space usage summary. The OP's 171 bytes of 'data' is probably ok.

    "The Keil linker cannot break up a single segment (which corresponds to a .c file) and remove the unused routines."

    I'm not certain, but I think I remember reading that the latest version includes a switch to remove unused functions.

    "If you're porting this software from another architecture, you may need to work on the code somewhat to make it more 8-bit-friendly."

    Absolutely.

  • " I think I remember reading that the latest version includes a switch to remove unused functions"

    Apparently it will only remove unused segments.

  • The Keil linker cannot break up a single segment (which corresponds to a .c file) and remove the unused routines.

    That's not 100% technically accurate.

    A source file is a module and it may be composed of many segments.

    A separate segment is generated for each function and for some data. The naming conventions used are specified in the manual: http://www.keil.com/support/man/docs/c51/c51_ap_segname.htm.

    This is not just a problem for code space, but for the compile-time stack overlay analysis as well.

    A not-so-obvious side-effect of overlay analysis is that it does not overlay the data of uncalled segments. It can't effectively do this anyway since it doesn't know where the function is called from. And, this allows the linker to sift through the functions and data and separate the used from the unused.

    There is a new LX51 Linker directive REMOVEUNUSED that removes unused program and data segments. But OVERLAY must be enabled. Overlay analysis is, after all, how the linker figures out which segments are used and which segments are not.

    Jon

  • "A separate segment is generated for each function and for some data"

    "There is a new LX51 Linker directive REMOVEUNUSED that removes unused program and data segments"

    Excuse me for being thick, but does this mean that if I have a single source file project with a main and two functions, only one of which is called, the uncalled function will not be linked and non-overlayed data space will not be allocated for that function?

  • does this mean that if I have a single source file project with a main and two functions, only one of which is called, the uncalled function will not be linked and non-overlayed data space will not be allocated for that function?

    Yes. That's the idea. To exemplify, I create a single-file project with 3 functions: main, func1 (which is used), and unusedfunc (which is unused).

    Both func1 and unusedfunc return an int and are passed 3 arguments. Additionally, they have a local 16-byte buffer.

    Following is the memory map from the LX51 linker with the REMOVEUNUSED directive specified.


    START     STOP      LENGTH    ALIGN  RELOC    MEMORY CLASS   SEGMENT NAME
    =========================================================================
    
    * * * * * * * * * * *   D A T A   M E M O R Y   * * * * * * * * * * * * *
    000000H   000007H   000008H   ---    AT..     DATA           "REG BANK 0"
    000008H   000011H   00000AH   BYTE   UNIT     DATA           _DATA_GROUP_
    000012H   000012H   000001H   BYTE   UNIT     IDATA          ?STACK
    
    * * * * * * * * * * *   C O D E   M E M O R Y   * * * * * * * * * * * * *
    000000H   000002H   000003H   ---    OFFS..   CODE           ?CO??C_STARTUP?0
    000003H   000022H   000020H   BYTE   UNIT     CODE           ?PR?_FUNC1?MAIN
    000023H   00002EH   00000CH   BYTE   UNIT     CODE           ?C_C51STARTUP
    00002FH   000039H   00000BH   BYTE   UNIT     CODE           ?PR?MAIN?MAIN
    
    * * * * * * * * *   R E M O V E D     S E G M E N T S   * * * * * * * *
       *DEL*:           000020H   BYTE   UNIT     CODE           ?PR?_UNUSEDFUNC?MAIN
       *DEL*:           00000AH   BYTE   UNIT     DATA           ?DT?_UNUSEDFUNC?MAIN
    

    The segments that the linker has determined are unused are listed in a new REMOVED SEGMENTS section along with the size, name and memory space they were allocated to.

    Hopefully, this directive will help some developers shrink program size and avoid warnings about unused code/data.

    Jon

  • more correctly:
    Hopefully, this directive will help some sloppy developers shrink program size and avoid warnings about unused code/data.

    If you need to have "delete of unused" to shrink program size, you do not work in a professional way.

    "unused segments" are quite common during development and OK at that time, but when the need to shrink program size comes up you either a) have some unused that should not be there in the first place or shrinking will not help you since the unused is to be used.

    I abhor ANY suppression of warnings.

    Erik

  • Sounds good. Perhaps this feature will motivate me to update my tools (at least once we make it past the next milestone so I can risk breaking things!)

  • "this directive will help some sloppy developers"

    Ouch!

    ""unused segments" are quite common during development and OK at that time"

    This is exactly when I need this new directive. My projects often fly close to the wire in terms of 'data' space. During development I often have quite a number of test/debugging functions in the source and it often happens that I comment out all calls to one or more of them during some test. I then get the infamous L107 warning, the linker therefore doesn't overlay locals in those functions and suddenly I have an address space overflow error. Then I have to comment out the uncalled functions, then later I have to uncomment them again, and so on.

    This feature is something quite a few of us have been waiting a long time for. Don't go telling Keil it's a bad idea now!

    "I abhor ANY suppression of warnings"

    I wouldn't be surprised if the new directive issues a warning when it removes code?

  • I wouldn't be surprised if the new directive issues a warning when it removes code?

    Nope - no warning. IF you specify this directive, the linker assumes you know what you're doing.

    You do, however, get a nice listing of all the memory you just saved.

    * * * * * * * * *   R E M O V E D     S E G M E N T S   * * * * * * * *
       *DEL*:           000020H   BYTE   UNIT     CODE           ?PR?_UNUSEDFUNC?MAIN
       *DEL*:           00000AH   BYTE   UNIT     DATA           ?DT?_UNUSEDFUNC?MAIN
    

    Jon