Comilier optimisation, expected reduction

[CarlFST60L]

Hi,

We have just completed redesigning an old product we had written in assembly. The assembly code (we wrote it about 5 years ago for HS08), the processor runs a GSM / GPRS / GPS device with various other specific functions. In assembly, the code is about 5Kb. Now we have re written the code in C and the project has hit the upper limit of 16Kb with about 90% of the code complete. (Part is S08AC16)

Using the smart sliders I set to optimise for code size, and out of 16Kb, it made less than 40 bytes difference over the default settings. So 40 bytes out of 16,000 bytes when optimised for size. Is this 'normal'?

I can obviously see some minor gains in writing my code more efficiently, which I will work on.

Is there something more I can do? Is there some documentation on writing code that Codewarrior can optimise better i.e. Do's an Dont's? Are there other compilers out there I can use that will optimise the code a better? Should I just be writing some of these functions in ASM?

I am quite suprised at how much larger the C code is over assembly, it will be nearly 5 times larger. The Assembly code is writted to be 'easy to read' to, not to be small.

[CompilerGuru]

The default settings are pretty much for "optimize for size", so that's not as surprising as it looks.

Do you place the often used variables in near sections so the compiler is using direct access?

Also how different is the behavior of the code, in C it's easier to pass many arguments around or to use arithmetic with larger types than in asm.

Daniel

[CarlFST60L]

Hi Daniel,

We have some very fast interrupt code (high speed/load input capture compare) and 128bit encryption which all use the first page.

If this makes a big difference, I can certainly try moving one of the 64byte buffers out of zero page and replace that with a heap of 8bit / 16bit varibles. (I ran out of RAM yesterday and noticed I had 64 bytes free in zero page, so i just dumped a 64 byte buffer in there). Should I do this?

Regarding passing of arguments, its much nicer in C than assembly, I have my code mostly setup to use a couple of structures which contain various logical states of operation and driver information, so the functions just point to that structure or pass pointers to other varibles. Its certainly far easy to read and work on this C code than assembly, the code only took a week to write, but several weeks in assembly!

Having a quick read through some of the assembly, its quite clear that some functions do not compile to well, I am thinking I might rewrite some of the string functions as they take up excessive space (mostly due to allowing for return results I will never use).

Is there some documentation on 'writing effectient C code'? I can spend a few trying various option to learn what works and doesnt by trial and error, but, Im always trying to find the quickest way out!

[CompilerGuru]

The number of usages of global is a rough estimate of how much using direct addressing for the variable improves. Therefore placing a bunch of small (often used) variables improves the code desity probably more than a single buffer which is usually only used from few places.

The map file lists how many relacations are using a variable, you can use that to pick the most often used variables. Basically sort it per usage/byte size of the variable.

I think the S08 compiler manual has a chapter about writing efficient code, did not check, just out of memory. There are also some linker optimizations which might help a bit, depending on the code and data, for example overlapping identical strings (or constants/functions), check the linker manual.

Daniel

[CarlFST60L]

Thanks Daniel, I will look into it.

[bigmac]

Hello,

The map file will indicate the code space occupied by each function.  Check to see which functions occupy the most space, especially if you can establish an equivalence with the previous assembly code, and the size ratios are massively different.  These functions then may be contenders to re-write in assembly, since they will be the functions most likely to achieve a considerable reduction of total code size.

Particularly examine the size of your encryption functions.  It is possible that the C version may be less efficient, especially with the very long bit sequences. 

Are you using many library functions?  These will often have greater size that the equivalent function that you may write, because they cater for a wider scope than you require.  Obvioulsy don't use 16 bit variables within your functions where 8 bit variables will suffice.

Regards,

Mac

[CarlFST60L]

The map file is key to working out where the 'oversized' code, already I can see most things take up quite a bit more space than I would have thought. I guess its time to get my hands dirty and have a play.

Your right Mac, the library functions are substantially larger against the equivilant assembly. I guess this is because the library function need to be universal and deal with things not always required.

 

I am sure I remeber being taught that C compiliers were as good and even better than assembly code...