Why "volatile" is neccessary in this case?

Hello all,

I posted a question regarding using CLK_gethtime() in C6711 quite a time ago:
http://www.dsprelated.com/groups/c6x/show/7385.php

The problem was that I wanted to measure the execution time of some code
using CLK_gethtime() function, but the returned execution time went wrong
randomly (lesser than the expected value). I knew it went wrong because I could
alternatively probe a digital output to know the real execution time.

I had many doubts about my problem, such as the use of TOUT0 and TOUT1 as
GPIOs might cause interference with the internal timer0 and timer1, or wrong
configuration / initialization / calling DSP/BIOS objects / functions. Some doubts
were cleared by the help of this list members, and I also carefully read TI doc
concerning C6711 timer and CLK_gethtime to clear the others. But the problem
wasn't solved. I just abadoned it because I have another way to calculate the
executime time anyway.

Today, I have to back to the code because there is a need to get the execution
time by the program running in the board to send to another monitoring program.
I don't have a reason, but just try to add "volatile" to the variables used in the
exec time measurement code, surprisingly it works. And I've tested hundreds
times to believe it.

volatile LgUns uStart, uEnd, uExecTime;

uStart = CLK_gethtime();

//.... some code here

uEnd = CLK_gethtime();
uExecTime = uEnd - uStart;

I used to believe that "volatile" works for the following variable types:
* Memory-mapped peripheral registers
* Global variables modified by an ISR
* Global variables used by different threads
where reading the variable can be a mistaken reading its cached value if
optimization is on.

But I don't see same situation in the above code. Why the code goes wrong
without volatile?

Thanks for reading!
Regards,
Tien

---------------------------------
Stay in the know. Pulse on the new Yahoo.com. Check it out. Start a New Thread

Hi,
I also has strange situation with time measurement (see my post above)
but in my case "volatile" doesnot work..
May be your case this one- " Global variables modified by an ISR".
Hello all,
>
>I posted a question regarding using CLK_gethtime() in C6711 quite a time ago:
>http://www.dsprelated.com/groups/c6x/show/7385.php
>
>The problem was that I wanted to measure the execution time of some code
>using CLK_gethtime() function, but the returned execution time went wrong
>randomly (lesser than the expected value). I knew it went wrong because I could
>alternatively probe a digital output to know the real execution time.
>
>I had many doubts about my problem, such as the use of TOUT0 and TOUT1 as
>GPIOs might cause interference with the internal timer0 and timer1, or wrong
>configuration / initialization / calling DSP/BIOS objects / functions. Some doubts
>were cleared by the help of this list members, and I also carefully read TI doc
>concerning C6711 timer and CLK_gethtime to clear the others. But the problem
>wasn't solved. I just abadoned it because I have another way to calculate the
>executime time anyway.
>
>Today, I have to back to the code because there is a need to get the execution
>time by the program running in the board to send to another monitoring program.
>I don't have a reason, but just try to add "volatile" to the variables used in the
>exec time measurement code, surprisingly it works. And I've tested hundreds
>times to believe it.
>
>volatile LgUns uStart, uEnd, uExecTime;
>
>uStart = CLK_gethtime();
>
>//.... some code here
>
>uEnd = CLK_gethtime();
>uExecTime = uEnd - uStart;
>
>I used to believe that "volatile" works for the following variable types:
> * Memory-mapped peripheral registers
> * Global variables modified by an ISR
> * Global variables used by different threads
>where reading the variable can be a mistaken reading its cached value if
>optimization is on.
>
>But I don't see same situation in the above code. Why the code goes wrong
>without volatile?
>
>Thanks for reading!
>Regards,
>Tien
>
>---------------------------------
>Stay in the know. Pulse on the new Yahoo.com. Check it out.
> Start a New Thread

I'd be interested in knowing if you got the same results if you only
used uExecTime as volatile and left the other two as normal static
variables.

If your code is straight code that does not have multiple threads of
execution or interrupt handlers, then generaly volatile should not be
important.

Do you have any compiler optimizations turned on?

Are you using cacheing?

I believe volatile can be used as a modifier on any variable at any
time, it has the drawback in that it reduces things that can be
optimized significantly.
--- In c..., tien vuong wrote:
> volatile LgUns uStart, uEnd, uExecTime;
>
> uStart = CLK_gethtime();
>
> //.... some code here
>
> uEnd = CLK_gethtime();
> uExecTime = uEnd - uStart;
>
> I used to believe that "volatile" works for the following variable
types:
> * Memory-mapped peripheral registers
> * Global variables modified by an ISR
> * Global variables used by different threads
> where reading the variable can be a mistaken reading its cached value if
> optimization is on. Start a New Thread

Tien-
> I posted a question regarding using CLK_gethtime() in C6711 quite a time ago:
> http://www.dsprelated.com/groups/c6x/show/7385.php
>
> The problem was that I wanted to measure the execution time of some code
> using CLK_gethtime() function, but the returned execution time went wrong
> randomly (lesser than the expected value). I knew it went wrong because I could
> alternatively probe a digital output to know the real execution time.
>
> I had many doubts about my problem, such as the use of TOUT0 and TOUT1 as
> GPIOs might cause interference with the internal timer0 and timer1, or wrong
> configuration / initialization / calling DSP/BIOS objects / functions. Some doubts
> were cleared by the help of this list members, and I also carefully read TI doc
> concerning C6711 timer and CLK_gethtime to clear the others. But the problem
> wasn't solved. I just abadoned it because I have another way to calculate the
> executime time anyway.
>
> Today, I have to back to the code because there is a need to get the execution
> time by the program running in the board to send to another monitoring program.
> I don't have a reason, but just try to add "volatile" to the variables used in the
> exec time measurement code, surprisingly it works. And I've tested hundreds
> times to believe it.
>
> volatile LgUns uStart, uEnd, uExecTime;
>
> uStart = CLK_gethtime();
>
> //.... some code here
>
> uEnd = CLK_gethtime();
> uExecTime = uEnd - uStart;
>
> I used to believe that "volatile" works for the following variable types:
> * Memory-mapped peripheral registers
> * Global variables modified by an ISR
> * Global variables used by different threads
> where reading the variable can be a mistaken reading its cached value if
> optimization is on.

Wouldn't CLK_xxx functions eventually read a memory-mapped peripheral register,
specifically a timer? Then your code is on the list and you have your answer.

'Volatile' keyword has nothing to do with cache. It has to do with the compiler not
being able "see" a hardware level write-access to a memory location, and optimization
the compiler might perform based on a bad assumption about something it can't see.
If the compiler assumes that a memory location cannot possibly have changed because
there was no write-access since the last read-access, and optimization is enabled,
then "useless" read accesses may be optimized out. In that case the compiler uses a
previous value, for example a value hanging around in a register or temporary
variable from the last read-access.

That isn't going to happen with normal cache operation, but it can happen with the 3
situations you listed.

-Jeff Start a New Thread

Hi Jeff Brower,

Thanks for your reply.

--- Jeff Brower wrote:

> Tien-
> >
> > I used to believe that "volatile" works for the
> following variable types:
> > * Memory-mapped peripheral registers
> > * Global variables modified by an ISR
> > * Global variables used by different threads
> > where reading the variable can be a mistaken
> reading its cached value if
> > optimization is on.
>
> Wouldn't CLK_xxx functions eventually read a
> memory-mapped peripheral register,
> specifically a timer? Then your code is on the list
> and you have your answer.

I am confused here. At first, I thought, even I can't
look into CLK_xxx implementation, I know it must
eventually read the C6711 timer registers, but the
function must internally use volatile variables for
reading the registers by itself, and I don't have to
use volatile when assigning the function's returned
value to my variable. But later I find that if CLK_xxx
functions aren't normal functions but some macros, it
is right that I have to use volatile variables. So I
looked into clk.h to confirm the idea. But the
declarations of CLK_xxx functions in clk.h show that
they're functions, not macros. What am I wrong here?

> 'Volatile' keyword has nothing to do with cache. It
> has to do with the compiler not
> being able "see" a hardware level write-access to a
> memory location, and optimization
> the compiler might perform based on a bad assumption
> about something it can't see.
> If the compiler assumes that a memory location
> cannot possibly have changed because
> there was no write-access since the last
> read-access, and optimization is enabled,
> then "useless" read accesses may be optimized out.
> In that case the compiler uses a
> previous value, for example a value hanging around
> in a register or temporary
> variable from the last read-access.
>

Yes, you are right. I mistook about the internal
process of "optimization" when mentioning "cached
value".

> That isn't going to happen with normal cache
> operation, but it can happen with the 3
> situations you listed.
>
> -Jeff
>

Now I have another big confusing. I compile my code in
"debug" mode with no optimization:

Generate Debug Info: Full Symbolic Debug (-g)
Opt Speed Vs Size = Speed most critical (no -ms)
Opt Level = None
Program Level Opt = None

But the calculated exec time still goes wrong if I
don't use "volatile" modifier for my variables. Could
you explain what's heppening?

Thanks and regards,
Tien

__________________________________________________ Start a New Thread

Hi wbonner,

Thanks for your reply.

--- wbonner wrote:

> I'd be interested in knowing if you got the same
> results if you only
> used uExecTime as volatile and left the other two as
> normal static variables.

I've tested. It goes wrong if any of the 3 variables
isn't volatile.

For detail: uExecTime is a global var. uStart, uEnd
are local vars, used inside an ISR. uExecTime is
written inside that ISR and is read outside.

>
> If your code is straight code that does not have
> multiple threads of
> execution or interrupt handlers, then generaly
> volatile should not be
> important.

Yes, I did think so. My code has multiple threads and
ISR, but the references to uExecTime, uStart, uEnd are
just simple.

> Do you have any compiler optimizations turned on?

I've been using 2 build configurations for building
debug-enabled and release code. Where:

Debug:
Opt Speed Vs Size = Speed most critical (no -ms)
Opt Level = None
Program Level Opt = None
Release:
Opt Speed Vs Size = Speed most critical (no -ms)
Opt Level = File(-o3)
Program Level Opt = None

I think the use of volatile variables concerns Opt
Level = -o3. But it is very strange that without
"volatile", the calculated execution time still goes
wrong when the program is compiled in debug mode (I'm
well awared that code in debug mode runs slower, I
compared the calculated exec time with the output
signal in my output port, not between release and
debug code). I am very confused.

> Are you using cacheing?
Cache L2 is disabled. Jeff Brower has noticed me that
volatile does nothing with caching and I think he's
right. Please read his post. Did you mean another
thing?

>
> I believe volatile can be used as a modifier on any
> variable at any
> time, it has the drawback in that it reduces things
> that can be
> optimized significantly.
>

Now the new test (optimization off, but the code is
still wrong without "volatile") makes me more
confused. Do you have some ideas?

Thanks and regards,

Tien
>
> --- In c..., tien vuong
> wrote:
> > volatile LgUns uStart, uEnd, uExecTime;
> >
> > uStart = CLK_gethtime();
> >
> > //.... some code here
> >
> > uEnd = CLK_gethtime();
> > uExecTime = uEnd - uStart;
> >
> > I used to believe that "volatile" works for the
> following variable
> types:
> > * Memory-mapped peripheral registers
> > * Global variables modified by an ISR
> > * Global variables used by different threads
> > where reading the variable can be a mistaken
> reading its cached value if
> > optimization is on.
>

__________________________________________________ Start a New Thread

Hi Tien
if u are speaking about CLK_getltime();
of course this is function.
I dont see any macros for CLKmodule. which one?

I dont sure that all problem in optimization.
just now I am trying CLK function CLK_getltime(); with "volatile"
and see the same result as without this class.

but this result is not the same as for TIMER_getCount(hTimer_local);
function !!

regards
Oleg

__________________________________________________ Start a New Thread

Tien-

>> Wouldn't CLK_xxx functions eventually read a
>> memory-mapped peripheral register,
>> specifically a timer? Then your code is on the list
>> and you have your answer.
>
> I am confused here. At first, I thought, even I can't
> look into CLK_xxx implementation, I know it must
> eventually read the C6711 timer registers, but the
> function must internally use volatile variables for
> reading the registers by itself, and I don't have to
> use volatile when assigning the function's returned
> value to my variable. But later I find that if CLK_xxx
> functions aren't normal functions but some macros, it
> is right that I have to use volatile variables. So I
> looked into clk.h to confirm the idea. But the
> declarations of CLK_xxx functions in clk.h show that
> they're functions, not macros. What am I wrong here?

Maybe the functions are short and being expanded inline? They would seem
to need just a few lines of code to get a timer register value, and
therefore suitable for inlining. Have you looked closely at the generated
asm lang code?

> Now I have another big confusing. I compile my code in
> "debug" mode with no optimization:
>
> Generate Debug Info: Full Symbolic Debug (-g)
> Opt Speed Vs Size = Speed most critical (no -ms)
> Opt Level = None
> Program Level Opt = None
>
> But the calculated exec time still goes wrong if I
> don't use "volatile" modifier for my variables. Could
> you explain what's heppening?

My guess would be because some amount of "basic optimization" is still
occurring, maybe because of "speed most critical" or another Build Option
setting.

-Jeff Start a New Thread

First I want to mention that I just went back and realized that you
are using functions related to the DSP BIOS, and I have no experience
with those functions. The hardware I have spent the last year working
with is custom hardware, and I've not been able to re-allocate
resources to be able to load the bios and take advantage if its
features. As such, my knowledge is more general related to C/C++
language and compilers in general.

I did just go read the preconditions for using the call to
CLK_gethtime() and they indicate that interrupts must be disabled
prior to calling the function. CLK_getltime() doesn't have that
precondition listed. Also, gethtime is not listed as being reintrant,
and lists a bunch of registers that it modifies, while getltime is
listed as reintrant and only modifies a single register. I'd guess
that this aims more at the particular problem that you are running up
across, and the volatile solution is more of a symptom to the problem
than the actual problem.

--- In c..., tien vuong wrote:
> --- wbonner wrote:
> > I'd be interested in knowing if you got the same results if you only
> > used uExecTime as volatile and left the other two as
> > normal static variables.
>
> I've tested. It goes wrong if any of the 3 variables
> isn't volatile.
>
> For detail: uExecTime is a global var. uStart, uEnd
> are local vars, used inside an ISR. uExecTime is
> written inside that ISR and is read outside.
>
> >
> > If your code is straight code that does not have multiple threads of
> > execution or interrupt handlers, then generaly volatile should not
be important.
>
> Yes, I did think so. My code has multiple threads and
> ISR, but the references to uExecTime, uStart, uEnd are
> just simple.
>
> > Do you have any compiler optimizations turned on?
>
> I've been using 2 build configurations for building
> debug-enabled and release code. Where:
>
> Debug:
> Opt Speed Vs Size = Speed most critical (no -ms)
> Opt Level = None
> Program Level Opt = None
> Release:
> Opt Speed Vs Size = Speed most critical (no -ms)
> Opt Level = File(-o3)
> Program Level Opt = None
>
> I think the use of volatile variables concerns Opt
> Level = -o3. But it is very strange that without
> "volatile", the calculated execution time still goes
> wrong when the program is compiled in debug mode (I'm
> well awared that code in debug mode runs slower, I
> compared the calculated exec time with the output
> signal in my output port, not between release and
> debug code). I am very confused.
>
> > Are you using cacheing?
> Cache L2 is disabled. Jeff Brower has noticed me that
> volatile does nothing with caching and I think he's
> right. Please read his post. Did you mean another
> thing?

If you are not using L2 caching, then that shouldn't be an issue at
all. I've run into issues on my platform because I've enabled 64k
worth of cache, and I have to make sure that I'm not using DMA moves
on variables that may be located in the cache. In general on my
setup, I'm using the cache for locations of code, and not so much for
data storage.

> > I believe volatile can be used as a modifier on any variable at any
> > time, it has the drawback in that it reduces things that can be
> > optimized significantly.
> > Now the new test (optimization off, but the code is
> still wrong without "volatile") makes me more
> confused. Do you have some ideas?
>
> Thanks and regards,
>
> Tien
> >
> > --- In c..., tien vuong
> > wrote:
> > > volatile LgUns uStart, uEnd, uExecTime;
> > >
> > > uStart = CLK_gethtime();
> > >
> > > //.... some code here
> > >
> > > uEnd = CLK_gethtime();
> > > uExecTime = uEnd - uStart;
> > >
> > > I used to believe that "volatile" works for the
> > following variable
> > types:
> > > * Memory-mapped peripheral registers
> > > * Global variables modified by an ISR
> > > * Global variables used by different threads
> > > where reading the variable can be a mistaken
> > reading its cached value if
> > > optimization is on. Start a New Thread

The timer is obtained as a read of a memory mapped register. So, the
compiler does not see any writes to this location, but value keeps changing
in the background, so we need volatile, to let the compiler know that it
cannot optimize the read out, and that a fresh read is required every time.

Regds
JS

-----Original Message-----
From: c... [mailto:c...] On Behalf Of William
C Bonner
Sent: Friday, September 22, 2006 3:49 PM
To: c...
Subject: [c6x] Re: Why "volatile" is neccessary in this case?

First I want to mention that I just went back and realized that you
are using functions related to the DSP BIOS, and I have no experience
with those functions. The hardware I have spent the last year working
with is custom hardware, and I've not been able to re-allocate
resources to be able to load the bios and take advantage if its
features. As such, my knowledge is more general related to C/C++
language and compilers in general.

I did just go read the preconditions for using the call to
CLK_gethtime() and they indicate that interrupts must be disabled
prior to calling the function. CLK_getltime() doesn't have that
precondition listed. Also, gethtime is not listed as being reintrant,
and lists a bunch of registers that it modifies, while getltime is
listed as reintrant and only modifies a single register. I'd guess
that this aims more at the particular problem that you are running up
across, and the volatile solution is more of a symptom to the problem
than the actual problem.

--- In c..., tien vuong wrote:
> --- wbonner wrote:
> > I'd be interested in knowing if you got the same results if you only
> > used uExecTime as volatile and left the other two as
> > normal static variables.
>
> I've tested. It goes wrong if any of the 3 variables
> isn't volatile.
>
> For detail: uExecTime is a global var. uStart, uEnd
> are local vars, used inside an ISR. uExecTime is
> written inside that ISR and is read outside.
>
> >
> > If your code is straight code that does not have multiple threads of
> > execution or interrupt handlers, then generaly volatile should not
be important.
>
> Yes, I did think so. My code has multiple threads and
> ISR, but the references to uExecTime, uStart, uEnd are
> just simple.
>
> > Do you have any compiler optimizations turned on?
>
> I've been using 2 build configurations for building
> debug-enabled and release code. Where:
>
> Debug:
> Opt Speed Vs Size = Speed most critical (no -ms)
> Opt Level = None
> Program Level Opt = None
> Release:
> Opt Speed Vs Size = Speed most critical (no -ms)
> Opt Level = File(-o3)
> Program Level Opt = None
>
> I think the use of volatile variables concerns Opt
> Level = -o3. But it is very strange that without
> "volatile", the calculated execution time still goes
> wrong when the program is compiled in debug mode (I'm
> well awared that code in debug mode runs slower, I
> compared the calculated exec time with the output
> signal in my output port, not between release and
> debug code). I am very confused.
>
> > Are you using cacheing?
> Cache L2 is disabled. Jeff Brower has noticed me that
> volatile does nothing with caching and I think he's
> right. Please read his post. Did you mean another
> thing?

If you are not using L2 caching, then that shouldn't be an issue at
all. I've run into issues on my platform because I've enabled 64k
worth of cache, and I have to make sure that I'm not using DMA moves
on variables that may be located in the cache. In general on my
setup, I'm using the cache for locations of code, and not so much for
data storage.

> > I believe volatile can be used as a modifier on any variable at any
> > time, it has the drawback in that it reduces things that can be
> > optimized significantly.
> > Now the new test (optimization off, but the code is
> still wrong without "volatile") makes me more
> confused. Do you have some ideas?
>
> Thanks and regards,
>
> Tien
> >
> > --- In c..., tien vuong
> > wrote:
> > > volatile LgUns uStart, uEnd, uExecTime;
> > >
> > > uStart = CLK_gethtime();
> > >
> > > //.... some code here
> > >
> > > uEnd = CLK_gethtime();
> > > uExecTime = uEnd - uStart;
> > >
> > > I used to believe that "volatile" works for the
> > following variable
> > types:
> > > * Memory-mapped peripheral registers
> > > * Global variables modified by an ISR
> > > * Global variables used by different threads
> > > where reading the variable can be a mistaken
> > reading its cached value if
> > > optimization is on. Start a New Thread