MPLAB C30 compiler optimization options can be used

[William Premerlani]

Team,

For some time, I have incorrectly assumed that we cannot use any of the optimization options with the free version of the Microchip C30 compiler after the expiration of the evaluation time period. I was wrong about that! (Thank you very much, Claudio!)

It turns out that you can use some of the optimization options, any time, even with an evaluation compiler after the expiration of the evaluation time period.

Here is what you do:

Under the project tab of MPLAB, select build options. Go to the bottom of the list, to Project. This will open the project build options.

Under the MPLAV C30 tab, select the Optimization category. This will bring up a window with a plot of speed versus code size, and circles with the labels 0, 1, 2, s, and 3. The default selection is 0, but you can click on any of them. You select the optimization level by moving the cursor onto the the desired circle and clicking your mouse.

This will be useful to any of you who are using several options available under MatrixPilot, and who have run out of program space with a UDB3. Selecting optimization level 1 or 2 will trim the amount of program size a fair bit. In my case, it cut the program size from 13980 bytes to 11137 bytes, a reduction of about 20%.

Once again, thank you very much, Claudio.

Best regards,

Bill

[Claudio Carbone]

Happy to help William.
There should be another optimization possibility under the linker tab.that had given me the best results, possibly because I make big use of microchip libraries.
Also the way the microchip compilers work is that you can select whatever options you want but only those really available for your license will be taken into consideration.
Maybe the c30 is a bit outdated, my c32 has the habit of reporting wrong compiler flags for each compiler call.
That means that if I select O4, and have 15 source files, I'll get 15 warnings the flag's been ignored because of missing license.

Regards
Claudio
-- Sent from my LG Optimus 2x with K-9 Mail.

[Wouter van Verre]

Hi William, Claudio,

I was wondering if you have tested the impact those compiler optimizations have on the available RAM? I think I read somewhere(Im looking for the source, but I'm not sure if I can still find it) that some optimizations reduce program size, but also increase RAM usage.  Given that the USB3 is also running out of RAM, this might pose a problem, at least for the UDB3. 

Kind regards,

Wouter van Verre

Sent from my iPad

[Giulio Berti]

Hi,

I've tried now to compile the rollpitchyaw project with and without optimization, here the results:

without (ROM/RAM): 8631/1024

with -Os: 6628/1024 

Hope this helps,

Giulio

[Mark Whitehorn]

Hi All,

I may be confused, but I thought GNU gcc provided optimization levels [0:3] and s. Wouldn't the gcc license prohibit Microchip for charging a license fee to use optimization?

I'm assuming that optimization level O4 is supplied by a different compiler, and that it requires a commercial license.

By the way, MPLAB-X with the pic30-gcc v3.30 compiler has never given me any warnings about licenses at all.

regards,

--Mark

--
Mark Whitehorn
kd0...@gmail.com

[William Premerlani]

Hi Mark,

You must be correct, but this was not clear from the Microchip documentation, which seemed to imply that you could not access any compiler optimizations without a commercial license. Lucky for us, that is not the case, and it does seem that, yes indeed, optimization levels [0:s] and s are available.

Best regards,

Bill

[crashmatt]

Gulio,

Is that the static ram usage assigned at compile time? We should consider stack usage which might be bigger with optimised code size.

Rgds matt

[William Premerlani]

Team,

I finally got around to taking a look at what happens to ram usage
(both static and stack) when you turn on the -s compiler optimization
option. It goes way down!!
So, using the -s optimization option is a clear winner.

I took a look at the assembly code to see what is going on in the
following areas:

1. Program space goes down by around 20%.
2. Global variables stay the same, so that does not change.
3. Variables defined by the source code used locally in a function do
not change.
4. "Scratch pad" generated by the compiler to handle things like
function calls with large argument list goes way down.

In one case I noticed the stack usage for telemetry for Mark's Quad
code dropped from 96 bytes (which does not even include the print
buffer) to 4 bytes!!!

I did not look closely enough at the assembly code to see why that was
exactly, but I think it had something to do with the setup of the call
to printf.

By the way, the way that I compared the stack usage was by searching
the assembly code for "lnk", which appears at the beginning of each
subroutine uses the stack. It allots space on the stack for that
routine. I compared the amount of stack space allotted by each
subroutine with and without optimization, and saw that the amount of
stack usage usually went down by a lot. Sometimes it stayed the same,
but it never went up.

Anyway, as far as the users are concerned, if you get tight on program
space, you definitely want to use the -s compiler optimization.

As far as developers are concerned, we should develop without compiler
optimization, to make sure we are leaving enough memory margin for the
UDB3.

Best regards,
Bill

[William Premerlani]

Team,

There has been a report of problems with firmware built with with compiler optimization options turned on. In particular, problems with getting GPS lock, and rebooting. I have not had time to track it down.

Obviously, if you use compiler optimizations, it would be wise to do plenty of ground testing before doing any flying.

Also, it might be better to use the lowest level of optimization (1).

Best regards,

Bill