debuger show inadequate values

#include <string.h>
#include <stdio.h>
#include <LPC214x.H>


volatile int rc=0;
volatile float A0 = 15.2, B0 = 0.152;
int tst(const int iprivod,int id0, float iV0)
{  int iS0, iS2, it0, idx1, idt, iS_m=0x1234, it_m;
   iS_m = (int)(A0 * A0 /B0);
//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
//Locals window show here 0x40000468 for iS_m
//and 0x000005F0 if next line is commented

   iS_m = A0 * A0 ;
   it_m = A0/B0+0.5;
   id0 = iS_m;
   if(iV0 < 0.)
   {
      it0 = iV0/B0+0.5;
   } else {
     iS0 = iV0*iV0/(B0*2.);
   }
   if(id0 <= iS0)
   {     if(iprivod > 0)
                 {
            idx1 = 123;
                 } else idt = 321;//it_m;
         return 0;
   }

   iS2 = (id0 + iS0);

   if(0x1235 > iS_m)
   {
return iS_m;
   }
return 2;

}

int main (void)
{
  while(1)
  {
  rc=  tst(1,1520, 0.);
  }
}

 Optimisation?

Most likely this is due to optimisation:

You assign a value to iS_m, then immediately assign something else - without using the 1st value.

Any decent optimiser will remove the redundant first assignment, but what the debugger makes of trying to show the value at the source line that effectively no longer exists is anyone's guess!

Correct your source code to either remove the redundant assignment, or make it non-redundant!

 RE: Optimisation?

Seems that this is optimization (-O0 compiler key) and there is no way to turn it off.

This source code is reduced demo part of long function, were all variables are used, but effect with Locals window is the same

 RE: Optimisation?

Seems that there was the same case in thread http://www.keil.com/forum/docs/thread5371.asp

There is the same issue 2 years later :-/

 Not the same at all!

"Seems that there was the same case in thread http://www.keil.com/forum/docs/thread5371.asp "

No, that's not the same at all, is it?

For a start, it's 8051 - not ARM.

If you read to the end, you will see that it wasn't even the Keil Simulator - it was a 3rd-party simulator.

 RE: Not the same at all!

However, one question from that thread does apply:

Does your code actually work?

ie, is it just a problem to get the debugger to display the "right" value, or is the code actually performing "incorrectly"?

 RE: Not the same at all!

Yes, just the same problem. And both cases involved float point.

Originally I want to find what is wrong with code with float point operatons that work fine from main() and work fine from interrupt routine in debuger, but hang up in real processor...Code does not used any side effects in C terms, but as I just found there is some relation between float point in interrupt and simple int (32 bit) arithmetics in main loop

 RE: Not the same at all!

"what is wrong with code with float point operatons that work fine from main() and work fine from interrupt routine in debuger, but hang up in real processor."

Do you mean debugger, or Simulator?

If it works in the Simulator, but not the real target (which is opposite to the other thread that you cited), that suggests that you have some hardware interaction that causes the problem.

This could be a bug or fault in your hardware, or could be something perfectly normal that your software doesn't handle correctly - eg, another interrupt occuring - which you haven't (properly) accounted for in your simulation.

Unless your processor has hardware floating point support, remember that all floating point operations will include Library calls - are you sure that your FP library is safe for use from interrupts?
eg, is it reentrant? is it safe from atomicity issues?

 Clarification

"a bug or fault in your hardware"

In this context, by "bug" I mean a design flaw, and "fault" is something broken or incorrectly done.

You could, of course, have a combination of both...

 RE: Not the same at all!

I mean entity that run on Ctrl+F5 from mVison3.

I know that all floating point operations are Library calls , but I am sure that I use float point operation only in one place, so in general meaning(IBM PC's thread-safe general programming) this code is not re-entrant. Well, it may be not-interrupt-safe, then it should be mention somewere in docs, isn't it ?

I don't see or can't find this point in RV complier and library docs, the word "reentrancy" is mentioned only 3 times on page 5-9 without any regards to float point operations. May be I am wrong and missing some point ?

 RE: Not the same at all!

>Do you mean debugger, or Simulator?
Well, I mean Simulator (debug with simulator) :-/

 Definetely bug with locals showing

Well, now I have take screanshort

http://foto.rambler.ru/public/e/v/evgen_k/4/keil_bug/keil_bug.png

ft0 should be -0.5, but is shown as 2.001436 in locals window and as "0" in flying window (not shown), it0 should be = (int) -0.5,i.e 0 but is shown in locals as 1073747848 and as zero in flying window.

No interrups are called.