GNU/gcc optimization for size

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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
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=.\ reading the first
.text section hexadecimal address and converting it into a decimal

The other compiler's options I have used are:

-v -Os -Tflash.ld -nostartfiles -Wl,-Map=.\,--cref,-nostdlib -s



Re: GNU/gcc optimization for size
Quoted text here. Click to load it

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.

Re: GNU/gcc optimization for size
Quoted text here. Click to load it

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

Chuck F ( (
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: GNU/gcc optimization for size
Quoted text here. Click to load it

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

Site Timeline