Codesize for CW08 v3.1, 5.0 and 5.1

[jhaee]

Hi,
I am using CW for HCS08GT60 devices an have been for quite some time. Unfortunately I have to develop / service on some designs that use the FLASH almost completely. i am using the -Ou and -Os (-Of also but it has no effect on my code) optimizer options to minimize the code.

Recently I had to make a small change in a design that was originally created using the CW08 3.1. However since it has been some time since I have used the 3.1 and I didn't have it installed. I tried first to build it with the 5.0 version. Then to my amazement the linker was unable to fit the code. Then I tried the 5.1 version and the same thing happened. Finally I gave in an installed the old CW. then it worked. By comparing the map files for a different target (a bit smaller) it seems that the 3.1 is best at the optimization and the 5.0 is approximately 60 byte larger and with 5.1 it is even more.
I can see in the map file that the extra bytes are scattered among the various functions in 1 2 and 3 byte increases.

Is there anyone who knows if this is caused by some error correction in the compiler or is it just random. Should I be considering changing my designs compiled with the 3.1 to the 5.x to for better performance?

[CompilerGuru · Accepted solution]

Without having C code which generates the additional bytes in V5.0/V5.1 its impossible to say where you additional 0.1% of code is from. Could be fixes, could be just changes, which help for other patterns but make it worse for yours. Can you provide actual code samples, best if complete compilable parts?
To see how many bytes are missing, you can just make the areas in the prm file temporarily a bit larger so it links, don't forget to undo it tough :smileyhappy:.
Things to gain a few bytes:
- make sure your most often used variables are in the zero page, qualified in a section declared with __SHORT_SEG. (#pragma DATA_SEG __NAME SHORT_SEG)
- try to use -odocf="-or" or -odocf="-one". -odocf compiles the source with and without the given open, sometime its better with sometime without, -odocf picks the smallest one for you. This makes the compilation slower, but I would expect it to gain more than this 0.1% :smileyhappy:.
- use smaller and/or unsigned types if all values match, prefer (unsigned) char to int, unsigned int to plain int, int to long, ...
- there is a linker optimization to overlap the same code patterns (check the linker manual, don't remember the option by heart)

BTW. -Ou only changes the behavior if there is inline assembly in the same function, otherwise it is default. -Os and -Of are default too, so no wonder -of does not gain anything :smileywink:

Daniel

[jhaee]

Thanks for the advice , the -odocf="-or" shaved almost 1 % of my code size. so that it now fits with the new compiler, also it gave me room for the bug fixes that i have to make. =)