www.coridium.us/forum

I assume your code is something like

void somefunction()
int x=1;
if (x==0) {
dosomething();
}
}

In this case the compiler sees that x must be 1 so dosomething is
unreachable, so it optimizes it out.

Rather than declare everything volatile, which is NOT recommended, its
better to fix your code.

volatile should be used for hardware registers, or variables that can
be altered by another process, such as an interrupt. If you make
everything volatile, the size of your code will grow quite a bit.

What happens in this case?

void somefunction()
int x;
if (x==0) {
dosomething();
}
}

re the below... check in K&R's C Programming books - you have that,
right? As I recall, it says that local variables are not initialized.
So the answer to your question is that the compiler will issue a
warning like Accessing Uninitialized Variable. Of course, you would
never actually code like that; it's one of many classic coding errors.
There is a program called "lint" that will parse your C code modules
looking for these and far more subtle coding errors and some logic
errors.

volatile: this tells the compiler to always load the variable when it
is referenced, rather than trying to cache it in a CPU register to
avoid reloading. I use volatile only when a variable is access by both
an interrupt handler and some non-interrupt code. The compiler cannot
know, except using volatile, that a variable may be altered by an
interrupt routine. In RTOSes, with preemptive multitasking, this too
can be an issue.




--- In ARMexpress@yahoogroups.com, "Dan Lee" <danlee_58@...> wrote:
>
> What happens in this case?
>
> void somefunction()
> int x;
> if (x==0) {
> dosomething();
> }
> }
>

I have numerous examples in my code where a piece of code is
optimized out due to the initilization of a variable. How do you know
when this will occur, unless you go through the list file and look
for missing code.

Here is one example of what I am encountering.

void somefunction()
int x = 1;
{
if (x==0)
{
dosomething();
}
else
dosomethingelse();
}

The declaration for 'int x' must be 'volatile int x' or some code
will not be generated.

Also, since my code is in a 'while loop' a variable my change value
from one pass to another, other than an interrupt. If it was a
constant, I would declare it 'const int x' I have cases where the
result from one operation triggers an if - else like above, but the
result of the operation may be different on the next pass. While
these are local variables, they are affected by Interrupts and I/O
operations. It appears to me that the only safe way to write this
program is to declare most local variables as volatile.

> I still have to watch variables that are initialized to some value
> and then used in an 'if' or other decision statement, before they
are
> updated in the code. The compiler eliminates the code for the Not
> True condition, as if the variable is a constant.

The compiler IS doing the right thing here, the code it is eliminating
can never be executed.
But that code can be executed, as soon as the value in the variable is changed
by another operation.

I now understand what's happening to the code.

If a variable is initialized, then used in a decision block, like
an 'if' statement, but never changed within the local code, the
compiler will optimize out the 'not true' branch. However if the
variable is changed anywhere in the local code, this optimization
will not occur.

This is a problem for me, as my memory can be changed after the code
is compiled. That means that I have to declare all this type of
variable 'volatile'.

I would like to be able to turn this particular optimization off, so
I can compile without declaring these variables 'volatile'.

> This is a problem for me, as my memory can be changed after the code
> is compiled. That means that I have to declare all this type of
> variable 'volatile'.

I don't understand how the memory can be changed. If its due to an
interrupt between the initialization and the decision, then it truly
should be volatile.

>
> I would like to be able to turn this particular optimization off, so
> I can compile without declaring these variables 'volatile'.
>

Most optimization will probably eliminate unreachable code, but details
on the control is in

\Program Files\Coridium\man\html1\arm-elf-gcc.html

>
> Most optimization will probably eliminate unreachable code, but
details
> on the control is in
>
> \Program Files\Coridium\man\html1\arm-elf-gcc.html
>

I tried all the -O optimizations. Some just made my code too large for
the flash memory, but none helped with my problem. I tried turning some
other optimizations, but no help there either.

I tried to leave a variable un-initialized, and not declared volatile.
The compiler complained, but produced both branches, the 'if' and
the 'else', since it didn't know what to do.

I'll uninitialize all these variables, and delete the volatile
declaration. Then I'll check every one that has a warning to be sure
that it fits this problem.

IF you initialize a variable inside a function, then it is initialized
on EVERY entry to that function, so again decision code that is
executed prior to any explicit change to that variable will NEVER NEVER
be executed, and can be removed.

So once again, I do NOT understand why you are going round and round on
this. Please refer to most any C language reference manual that deals
with optimizations, and it will describe in detail what is going on.

I do understand what is going on, but let me explain my project a
little without revealing too much.
I am rewriting firmware that was written for an Intel 80xx
Microcontroller in the 1980s. I want to add some updated functions,
and delete obsolete functions.
The code was written in assembly language and fit into 32k of code
space.
The variables that I am concerned are Flags and Calibration values
that are loaded into flash memory. These control the flow of the
program, and can be changed without recompiling the program by
reflashing these memory locations.
For this reason there are no unreachable branches in this program. I
must have code generated for all branches.
I can achieve that by declaring all of these variables 'volatile',
but since the 2103 is a RISC processor, and the 80xx was a CISC
processor, I am finding that 32K is not enough memory, and I need to
reduce the code size as much as possible, and take advantage of all
optimizations.
Except for the memory size, I feel that the Armmite board is a
perfect host for this code, and I will do what is necessary to run
this program on this board. Shortly, I will be purchasing the source
for the Coridium flies, in order to tailor them to my needs and free
more memory space.