looking at the binary sizes of libalgobsec.a, compiled for different architectures using GCC, I noticed that the size for Cortex_M33F (49453 B) is notably larger than the size for the comparable Cortex_M4F (27841). Both architectures support an FPU, and similar instruction sets, from what I can see on Wikipedia and in the ARM architectures and processors forum; so I would expect similar compact code.
In case of the M4F, the size increase, in comparison to the non-FPU version, is only some hundred bytes, in case of the M33F it is around 12 KiB:
Is there a difference in GCC's compiler options (like, a different optimization choice) or some other conditions, that explain the binary size increase on M33F?
Solved! Go to Solution.
After our check, every other MCU uses -fdata-sections in compiling options, but M33F doesn't.
-fdata-sections could decrease size of generated files.
So M33F library size is bigger than others.
thank you for your reply.
Option -fdata-sections tells the compiler to put each variable into its own section, rather than using one .data vs .bss section per object file; this allows the linker to remove variables from the executable that are not needed by the functions actually used, which would not be possible without that option.
Using or not using this option should not have such a big impact on the size of .text section, the compiled functions, though;
actually, when not using -fdata-sections, code can be slightly smaller (probably because the compiler knows relative offsets of variables and can create more efficient code).
What I'm seeing is that functions in the M33F-lib.a are 1.3x to 3x larger than the same functions in M33 or M4F libs. These factors seem to suggest that optimization is not activated for M33F at all. Could you please check again, whether optimization is configured the same for M33F as for M33, M4 and M4F?
By the way, did you try to run M33F library on your host MCU? If yes, could you let us know if you get some problem?