Hello, We worked previously with the uVision3 with following components and optimization level 0:
uVision3 V3.70 Toolchain: MDK-ARM Standard 3.30 C Compiler: V3.1.0.942 SARMCM3.DLL: V3.30 DARMSTM.DLL: V1.37
Compiler Control string: -c --device DARMSTM -g -O0 --apcs=interwork
The BUILD OUTPUT is: Program Size: Code=109260 RO-data=12552 RW-data=820 ZI-data=16840
With the uVision4 we got memory problems with this optimization level!!!
vVision V4.20.03.0 Toolchain: 4.20 C Compiler: V4.1.0.644 SARMCM3.DLL V4.20 DARMSTM.DLL V1.62
Compiler Control string: -c --cpu Cortex-M3 -g -O0 --apcs=interwork
And the BUILD OUTPUT is: .\Debug\objects\rectifierDebug.axf: Error: L6220E: Load region LR_MyProject size (127148 bytes) exceeds limit (122880 bytes). Region contains 148 bytes of padding and 0 bytes of veneers (total 148 bytes of linker generated content).
For another project (much smaller memory size, app. 73k) which was possible to build with uVision4, I found that the memory size was app. 3k higher as I build it with uVision3.
I saw that the compiler control string is different, but how can I cahnge this. What is the reason for this much more memory??? I think it's not normal that the memory size increase with a new compiler version!
Thank you for support. Best regards, Carsten
But -O0 and -Ospace need not be a good combination.
Some optimize-for-space strategies are directly incompatible with debugging - such as identifying multiple functions that have a similar "tail" and have one of the functions jump into the other function. You would be very surprised if you single-stepped an unoptimized build and suddenly found yourself inside a completely different function.
-O0 is mainly a "make it debuggable" command to the compiler. It is not a command that is well suited for speed or size optimizations.