I'm working to cross compiling (for arm, with arm-elf-* tools) some pieces of code and I have to pay really attention to the compiled size. Some tests with others compilers (arm, m16c, 8051) show me that the GNU performance, in respect with the size consumption, are the worst. I will ask you if my tests are credible or not? And If not, I hope someone can tell me were I'm wrong. This are the tests results: ARM 37324 Bytes 8051 37903 Bytes M16C 42132 Bytes GNU 47488 Bytes I have obtained the GNU value of 47488 Bytes from the Map file (I create it with the linker option -Wl,-Map=.\Map.map) reading the first .text section hexadecimal address and converting it into a decimal value. The other compiler's options I have used are: -v -Os -Tflash.ld -nostartfiles -Wl,-Map=.\Map.map,--cref,-nostdlib -s -o... Thanks, Maja
GNU/gcc optimization for size
Started by ●September 25, 2004
Reply by ●September 25, 20042004-09-25
>Some tests with others compilers (arm, m16c, 8051) show me that the >GNU performance, in respect with the size consumption, are the worst. >I will ask you if my tests are credible or not? And If not, I hope >someone can tell me were I'm wrong.Throw out the M16 and 8051 results. The instruction sets are different from ARM so that's like comparing apples to oranges. I assume that by GNU, you mean the ARM version of the GNU compiler? You might want to look at the actual code generated between the ARM and GNU compilers to see what the difference is.
Reply by ●September 25, 20042004-09-25
> This are the tests results: > ARM 37324 Bytes > GNU 47488 BytesThe other tests are meaningless. I assume that by "GNU" you mean arm-*-gcc, and by "ARM" you mean the ARM tools from some other vendor. If this is the case, then the size difference you show above is a bit more than I would expect, but not out of reasonable boundaries. The problem is that you might be including some imported code (inlined functions or library code) which could be skewing the results. You should compare function-by-function the code size emitted and see which functions differ by the greatest percentage, then analyze those specific functions in detail to see what constructs are generating the worst output from gcc. If one compiler is using mixed ARM/THUMB instructions, then that could more than entirely explain the difference, BTW. The other interpretation that comes to mind for your post is that by "ARM" you mean arm-elf-gcc and by "GNU" you mean an x86-targeted version of gcc. In that case, the results are almost entirely meaningless.
Reply by ●September 25, 20042004-09-25
Gary Kato wrote:> >> Some tests with others compilers (arm, m16c, 8051) show me that >> the GNU performance, in respect with the size consumption, are >> the worst. I will ask you if my tests are credible or not? And >> If not, I hope someone can tell me were I'm wrong. > > Throw out the M16 and 8051 results. The instruction sets are > different from ARM so that's like comparing apples to oranges. > > I assume that by GNU, you mean the ARM version of the GNU compiler? > > You might want to look at the actual code generated between the > ARM and GNU compilers to see what the difference is.Examine the code generated for your source alone. The libraries linked can cause wildly different load modules, dependant both on the library quality and atomicity. For example, a fully compliant printf routine (which is really an interpreter) involves many many code modules, most of which will never be used in a particular application. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
