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