I'm using float 24 bit to store a floating point value in a compiler MRK III from NXP. It stores the 24 bit float value as 3 byte Hex in Data memory.
Now when I'm using IEEE 754 float point conversion to retrieve the number back from binary to real, I'm getting something very strange.
Let me put it this way with an example -
Note - "since my compiler supports float 24 bit (along with float 32), I'm assigning value something like this."
Sample Program :
float24 f24test;
float f32test;
f32test= 2.9612;
f24test= (float24)f32test;
Output in debug window (global variable) :-
f32test = 2.961200e+000
f24test = 2.9612e+000
Values stored in the DM(Data Memory at the same time) as captured from debugger -
f32test = 40 3d 84 4d (in hex)
f24test = 02 3d 84 (in Hex)
PROBLEM :-
Now when I'm trying to convert f32test = 40 3d 84 4d (in hex) in binary & then back to floating using IEEE 754 , I could retrieve 2.9612.
While at the same time when I'm trying to convert f24test = 02 3d 84 (in Hex) in binary & then back to floating using IEEE 754 , I could not retrieve 2.9612 instead some weird value.
I'm looking into this wiki page to refer about the floating point arithmetic's -: http://en.wikipedia.org/wiki/Single-precision_floating-point_format
I'm confused why it is not working for the float 24 if I'm using the same format for 1 sign bit, 8 bit exponent & 15 bit Mantissa. (In float 32 it is 1 sign bit, 8 bit exponent & 23 bit Mantissa.)
Can any one of you guys help me to get the value 2.9612 back from f24test = 02 3d 84 (in Hex) ???
Please do , I've been struggling with this for past 15 hours :(
Thank you in advance:)
f32test = 40 3d 84 4d (in hex)
f24test = 02 3d 84 (in Hex)
In IEEE 754 floating-point formats, the floating-point exponent is stored with a bias. Clearly, whoever designed the 24-bit floating-point format you are referring to did not choose to use the same bias system as is used in IEEE 754 binary32, since the values of the exponent bits of the two representations above do not match despite the exponents of both being represented with 8 bits (according to you).
In the 32-bit representation, the exponent is represented with the bits 0x80, which sounds about right for the representation of a value between 2 and 4.
You could start from the hypothesis that the exponent in the 24-bit format has a bias of 0x04, and confirm this with more values. A single value is not enough for us to make sense of a 24-bit floating-point format that isn't part of the IEEE 754 standard and is obviously designed with some exotic choices.
I suppose this is an old post, but I will compliment this with the experience I am going through right now...
I am also trying to discover how NXP represents the float24 data type. I am writing a small test macro that will be inserted in a much larger piece of code, and I am trying to utilize the float24 data type since the regular float data type seems to cause problems (I am an intern, so I am unsure why it is causing problems, perhaps the target I am writing code to cannot support 32 bit float numbers?).
There were some notes left from some other engineer in the larger piece of code that states something like this...
/* ByteValue[0] : mantissa bits m7..m0
ByteValue[1] : sign bit, mantissa bits m14..m8
ByteValue[2] : exponent e7..e0 (signed, 2s complement repres.)
Actual value is
f = s * ( 2^(-1) + m14 * 2^(-2) + ... m0 * 2^(-16) ) * 2^e */
Sadly, this new information is still cryptic (What is the bias suppose to be? Is there suppose to be a bias? What is the variable 's'? Assuming it means the sign bit, why is it being multiplied by the mantissa since multiplying can imply the result equaling 0 if the sign bit is 0? etc.).
However, this may show that the structure of this number is different. The sign bit isn't the MSB anymore, it is listed right after the exponent. This would also imply that, in your case, the exponent is +2 (since your hex number starts with 0x02, and that corresponds to ByteValue[2]).
I hope this helps anyone stumbling upon this post. I am still trying to solve this myself. Please post any new thoughts.
