c54x c compiler optimization tips?

[Mike]

I was wondering what I need to watch out for when using the optimize
feature on the compiler.

For example, I noticed that -o0 and -o1, the code still seems to work
fine. At -o2 and above, it stops working.

What types of things do I need to keep in mind when I use these compiler
options?
Thank you.
-Mike

[Jack Klein]

On 14 Oct 2003 17:50:23 -0700, [email protected] (Mike) wrote in
comp.dsp:

> I was wondering what I need to watch out for when using the optimize
> feature on the compiler.
>
> For example, I noticed that -o0 and -o1, the code still seems to work
> fine. At -o2 and above, it stops working.
>
> What types of things do I need to keep in mind when I use these compiler
> options?
> Thank you.
> -Mike

First, can you be sure that it is the optimizer, and not the code?

One of my programmers wrote buggy code (for a c28x) that I caught in a
code review. His defense was that the code worked when he tested it,
which is no real test at all for writing invalid C. I tested his code
myself, first building it as he did with no optimization. A compiler
bug gave the "right" results (the results he wanted) up to -01, but
the optimization fixed it at -o2 and above so the result was what the
C standard said it should be.

There might be bugs in the optimizer, that would not be too unexpected
with any compiler. But a lot of the complaints about optimization
bugs are due to sloppy or invalid coding as well. So check the code
that seems to go wrong when optimized.

I haven't tried it with the c54x, but PC Lint works just fine with C
code for the C28x, after the usual tweaking. The free, open-source
splint (www.splint.org) might be useful if the budget does not extend
to buying PC Lint, if you are coding in C and not C++.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Keith Larson]

Hi Mike

One of the more common mistakes is to not realize that by not specifying
'volatile' the optimizer is free to eliminate some variables under the
pretense that that they are static. It is like saying that if the
compiler writes to a memory location, that memory location should be
assumed to hold the value that was written to it.

In the example below the compiler reads location 'A' once and afterwards
might decide that there is no need to read it again and again since the
location is not being modified. The optimizer *did* do the right thing. No?

#define TIMER (int *)0x808020 // location of my timer
for(;;)
{
while(*TIMER!=0); // wait for timer to time out
}

The correct way to deal with this is to add the keyword 'volatile'
telling the compiler that some other hidden routine (maybe an interrupt)
or piece of hardware (DMA counter etc...) is changing the value.

#define TIMER (volatile int *)0x808020 // location of my timer
for(;;)
{
while(*TIMER!=0); // wait for timer to time out
}

Another common question is why symbolic debugging seems to stop when the
optimizer is used. In a similar way, the optimizer is not keeping all
of the variables in memory, leaving the debugger with nothing to watch.
The newer compilers are better at being able to track things that have
become register variables but it is not always infallable. An example
would be a loop counter.

for(x=0;x<100;x++)
*c++=*d++;

In this case the compiler may decide that it would be better to use the
onchip block repeat hardware, which incidentally works by counting down
instead of up. The optimized re-write would look like this, and the
value of x would not even be possible unless the debugger was told that
x=100-RC

for(x=100;x>0;x--)
*c++=*d++;

Hope this helps
Keith Larson
================================================== ==============
Mike wrote:

I was wondering what I need to watch out for when using the optimize
feature on the compiler.

For example, I noticed that -o0 and -o1, the code still seems to work
fine. At -o2 and above, it stops working.

What types of things do I need to keep in mind when I use these compiler
options?

Thank you.
-Mike
+------------------------------------------+
|Keith Larson |
|Member Group Technical Staff |
|Texas Instruments Incorporated |
| |
| 281-274-3288 |
| [email protected] |
|------------------------------------------+
| TMS320C3x/C4x/VC33 Applications |
| |
| $150 TMS320VC33 DSK's ARE AVAILABLE NOW |
| |
| TMS320VC33 |
| The lowest cost and lowest power |
| floating point DSP on the planet! |
| 500uw/Mflop |
+------------------------------------------+

[Mike]

Keith,
Thanks for your help. I have put volatile all over the place, but a couple
of my interrupts are still not happening. (Unless I do a level 1)

Could there be anything else that I am missing?

Thanks!

-Mike


Keith Larson <[email protected]> wrote in message news:<[email protected]>...
> Hi Mike
>
> One of the more common mistakes is to not realize that by not specifying
> 'volatile' the optimizer is free to eliminate some variables under the
> pretense that that they are static. It is like saying that if the
> compiler writes to a memory location, that memory location should be
> assumed to hold the value that was written to it.
>
> In the example below the compiler reads location 'A' once and afterwards
> might decide that there is no need to read it again and again since the
> location is not being modified. The optimizer *did* do the right thing. No?
>
> #define TIMER (int *)0x808020 // location of my timer
> for(;;)
> {
> while(*TIMER!=0); // wait for timer to time out
> }
>
> The correct way to deal with this is to add the keyword 'volatile'
> telling the compiler that some other hidden routine (maybe an interrupt)
> or piece of hardware (DMA counter etc...) is changing the value.
>
> #define TIMER (volatile int *)0x808020 // location of my timer
> for(;;)
> {
> while(*TIMER!=0); // wait for timer to time out
> }
>
> Another common question is why symbolic debugging seems to stop when the
> optimizer is used. In a similar way, the optimizer is not keeping all
> of the variables in memory, leaving the debugger with nothing to watch.
> The newer compilers are better at being able to track things that have
> become register variables but it is not always infallable. An example
> would be a loop counter.
>
> for(x=0;x<100;x++)
> *c++=*d++;
>
> In this case the compiler may decide that it would be better to use the
> onchip block repeat hardware, which incidentally works by counting down
> instead of up. The optimized re-write would look like this, and the
> value of x would not even be possible unless the debugger was told that
> x=100-RC
>
> for(x=100;x>0;x--)
> *c++=*d++;
>
> Hope this helps
> Keith Larson
> ================================================== ==============
> Mike wrote:
>
> I was wondering what I need to watch out for when using the optimize
> feature on the compiler.
>
> For example, I noticed that -o0 and -o1, the code still seems to work
> fine. At -o2 and above, it stops working.
>
> What types of things do I need to keep in mind when I use these compiler
> options?
>
> Thank you.
> -Mike
> +------------------------------------------+
> |Keith Larson |
> |Member Group Technical Staff |
> |Texas Instruments Incorporated |
> | |
> | 281-274-3288 |
> | [email protected] |
> |------------------------------------------+
> | TMS320C3x/C4x/VC33 Applications |
> | |
> | $150 TMS320VC33 DSK's ARE AVAILABLE NOW |
> | |
> | TMS320VC33 |
> | The lowest cost and lowest power |
> | floating point DSP on the planet! |
> | 500uw/Mflop |
> +------------------------------------------+