Trouble with floating point conversions

[Ted Jackson]

Hi. If I create a C floating point number (ab) and set its value equal to a 32 bit integer (or a constant), the integer and the float are very different, at least as reported by the STVD debugger watch window. Normally, I'd expect to see a clean conversion to float. Float to int32_t appears to be working. Just not (any) integer to float. I know I'm dealing with an 8-bit MCU. But what am I doing wrong? Thanks.

[Ozone]

> ...the integer and the float are very different at least as reported by STVD debugger watch window.

Not sure what the problem is. The representation in the debugger view ?

> Hi. If I create in C a floating point number (ab) and set its value equal to a 32 bit integer ...

This implies an implicit cast by the C standard.

Are you aware of the difference between float and double, especially in regard to constants (string literals) ?

[Ted Jackson]

I'm not sure myself, if it's the IDE's watch variable interpreter, firmware, c library, whatever. Float to int appears to work. Just not int to float.

I don't know that difference. Please tell. Oh, if you mean that float occupies half the bytes of a double, then yes, I know that difference.

[Ozone]

You could check with the memory at the address of said variable, assuming IEEE 754 conforming representation.

BTW, "1.0" is not a floating point constant.

By C standard, it would be double. I suppose your compiler knows the "f" suffix.

What happens in the debugger display if you assign a floating point constant (like: "float ab = 1250.0f;") ?

Maybe the debugger has some endianess issues ?

[Ted Jackson]

'delb' is a 16-bit uint that is set to 1 and that line has just been executed. Watch window says delb is 0. Memory window says delb is 0. I'm just using the free STVD Visual Develop IDE from ST with the COSMIC compiler. I don't know how to get more basic than that.

Oh, you're right. But 'f' didn't seem to make any difference.

[Ted Jackson]

Ozone, I asked in electronics stack exchange. And someone there evidently had the right answer. The optimizer. The optimizer that doesn't calculate variables that ultimately aren't going to be used. Explains a lot. Thanks for your help.

[Philipp Krause]

I've seen such issues before: A combination of optimization and wrong debug info. When the variable is in a register at a certain point, the debug info should say so instead of claiming that it is in a memory location, so in the end this could be a compiler bug resulting in wrong debug info (but otherwise correct code).

You seem to be experiencing the problem in STVD (and thus probably in the Cosmic compiler, as AFAIK, Raisonance isn't used much these days and STVD doesn't support IAR and SDCC). But other compilers also have such problems: https://sourceforge.net/p/sdcc/bugs/2700/ (this type of bug often isn't found quickly, as the code still behaves correctly, it only looks wrong when pointing a debugger at a specific place manually).

[Ted Jackson]

Yes, I am using STVD which is making use of the COSMIC compiler. Even after turning off optimizations, the problem of variables not being included in the code persists, evidently if the variable isn't ultimately required later in code. So the question arises, "How far must one go to fool or force the compiler into thinking that the variable must be compiled in? What exactly are the criteria for a variable being consigned to oblivion? And why the heck is STVD ignoring the fact that I turned off optimizations? Have they included cruel and vengeful AI into the optimizer?" I've tried dressing the variable up with extra code after the assignment/declaration to try to fool the compiler into coding it. Doesn't seem to work. The compiler seems to effectively say, "I'm wise to your attempted deception, pathetic developer. And you can't make me!" Thank you Philipp. And thanks to all of you learned gurus who take the time to help us lowly, pathetic newbies.

https://www.youtube.com/watch?v=gYG_4vJ4qNA

Fortunately, ST's chips appreciate (saving) power too! But how to force them to do my will is the question.

Also fortunately, it appears that a simple increment will fool the AI optimizer! At least now I know why breakpoints often don't stay where they're placed and how to read the debugger window to identify the removed code quickly. Learning... Making progress...

[Philipp Krause]

I rarely use any compiler other than SDCC, GCC and LLVM, so I don't have much experience with Cosmic, but:

Have you tried making the variable volatile?