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 in reality, the size hasn't increased so much.
Program Size: Code=109260 RO-data=12552 RW-data=820 ZI-data=16840
Both the code and the RO-data has to be stored in the flash. If the RO data isn't compressed, you needed 121812 bytes. And limit was 122880.
With v4 you now need 127148 bytes. So an increase of 4.4%. That is not a big change, and definitely possible in case they have made changes to the code generator to speed up the generated programs.
Note that optimization 0 just means that the compiler does not run extra optimization steps, thereby avoiding problems with expressions without side effects being thrown away and statements being reordered.
But even at optimization level 0 - no optimization - it's possible that they change the code generator to create more efficient code. A Cortex M3 processor have Thumb2 instructions making it unable to directly work with 32-bit immediate constants or addresses, making it important for the compiler to load 32-bit values into registers or storing 32-bit pointers in memory cells instead of trying to load as immediate data to make sure that they can take advantage of a 32-bit core even when limited by 16-bit instruction size.
Thank you very much
but I have still one question. You wrote "it's possible that they change the code generator to create more efficient code". How is it possible, because -Ospace is used as default, isnt' it?
Thank you again. 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.