I'm using Microvision 4 C compiler Armcc.Exe v4.0.0.524 When this compiler converts a floating point number (single precision) to INT8 it doesn't handle negative values properly. For example INT8 Function::Convertnumber(F32 number) { INT8 return; return = number; }
this only works for positive numbers. If a negative value is passed into the function 0 is returned only. Seems like a bug in the compiler. I can't find any errata concerning this but i'm wondering if anyone else has noticed this problem and how it was solved?
the simple example is enough to illustrate the problem.
No, it's not, because like I said before: it will not even compile.
So the only problem this could possibly illustrate is that your command of the C++ programming language is not up to your own expectations.
The reason I asked for a more fleshed-out example was that there's simply no way this is the actual function the problem you described appears in. For two reasons:
1) to exhibit any run-time problem at all, the actual problematic would have had to survive compilation. This one doesn't.
2) to exhibit the particular problem you claimed, the result of that convesion would have to have some way of making it out of that function. In this one, it doesn't.
So whatever a function with the actual problem in it looks like, it would have to be so different from the sketch you posted that the latter cannot possibly serve as an illustration of the former.
First off, I see why you (well some of you anyway) guys are getting your panties in a bunch. I quickly edited some IP code which I can not legally provide here and noticed I put return instead of a variable in the declaration, for that I apologize.
INT8 function::convertnumber(F32 number) { INT8 rc;
rc = number; return(rc); }
The code is C++ and the compiler stated was correct. It compiles C++ code quite well, so for the suggestions there thanks, but not an issue whatsoever. The issue was not the compiler after all, thankfully, as that would have really been a doozy of a problem in more ways than you would like to know. It was actually a configuration issue which wasn't real easy to determine, associated with the typedef for the INT8 not being done properly as a few of you pointed out. Sorry to raise a problem that wasn't a problem. take care
It was actually a configuration issue which wasn't real easy to determine, associated with the typedef for the INT8 not being done properly as a few of you pointed out.
Would you care to elaborate?
It had to do with a configuration tool unrelated to KEIL procucts. The compiler is working as intendended, sorry again for any confusion and thanks again for responding.
It had to do with a configuration tool unrelated to KEIL procucts.
I'll take that to mean that the INT8 type was actually not, like you had posted before,
typedef signed char INT8;
but rather ended up being some variation of
typedef unsigned char INT8;
correct