We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, the following code for STM32F4 (Cortex-M4):
float fZero= 0.; float fInfinity; short sTestPlus, sTestNeg; int main( void){ fInfinity= 1.f/fZero; sTestPlus= fInfinity; fInfinity= -1.f/fZero; sTestNeg= fInfinity; while(1); }
should result in the values sTestPlus= 0x7FFF and sTestNeg= 0x8000. Instead it produces 0xFFFF and 0x0000.
The reason is, that the compiler uses the signed 32bit convert (leading to the correct result 0x7FFFFFFF and 0x80000000), and then just cuts out the lower short, which is really poor.
As I understand, it is no problem with Cortex M4 to do float to signed16 using the VCVT command in a more sophisticated way (specifying 16bit).
Is there a way to get this done?
but I do not really understand your posts
My point is that the behavior of your code isn't defined by the C standard. It's not defined by the compiler reference manual either, as far as I can see. You may have found some compiler features that can be used in your code. But since you are relying on undocumented behaviour, you'll have to verify that the undocumented features are still there every time you upgrade the compiler or use a different library (microlib?) or make other significant changes to you build environment.
But conversion from int to float is nothing mystical - why should this be not documented?
At least - if I should be able to use Cortex M4 efficiently, it would be necessary that there is some inline/intrinsic possibility to use this VCVT command with its full power.
Well, I don't know. Why don't you ask Keil? It's their documentation, after all. Or maybe I didn't dig deep enough.
Definitely. Sounds like a feature request that should be directed to Keil.
But conversion from int to float is nothing mystical
It's also not not what we've been talking about here. That was float-to-int, not int-to-float.
- why should this be not documented?
Why should it be? Per the language definition your code causes undefined behaviour. That means the compiler itself can crash, or generate code that returns a different, random number every time, and still be 100% correct, without the need to document anything.
Yes, ARM could have decided to define a particular behaviour in this cause, and maybe they did. In that case, and only then, they should have documented this decision. But the fact that nobody seems to have found any such documentation would seem to indicate that no such decision was made.
Summary: this code is buggy. It relies on unwarranted assumptions. For the ARM compiler, these assumptions actually are incorrect, so the bug became noticeable.