2
\$\begingroup\$

I have in hexadecimal representation a IEEE-754 Floating Point:

uint32_t _u_IEEE_754 = 0x41100000; //9.0

The decimal representation is: 9.0

I am working in C under embedded system.

I want to get the integer and decimal part separately, from the number in hexadecimal. I can't use floating point. I have no idea where to start. Which idea would be of great help to me.

\$\endgroup\$
10
  • 1
    \$\begingroup\$ Separate out the exponent, mantissa and the sign bit. Then use the exponent to find where the binary (decimal) point is. Split the mantissa there. Add the implied 1 to the most significant part and you have the whole number and decimal part. There are quite a lot of edge cases though which have to be separately handled. Alternately, see if you can find the code for rounding off of floating point numbers in any standard library. That code should also have been doing the same thing you want. \$\endgroup\$
    – AJN
    Sep 3, 2020 at 2:26
  • \$\begingroup\$ What do you mean "I can't use floating point"? You are using floating point. Do you mean you can't use the floating point type? Why? \$\endgroup\$
    – TimWescott
    Sep 3, 2020 at 2:35
  • \$\begingroup\$ If you can guarantee that your floating point numbers are well-formed (i.e., none of the edge cases that @AJN is talking about) then you can write your own converter. But really -- there's a reason for standard libraries. \$\endgroup\$
    – TimWescott
    Sep 3, 2020 at 2:36
  • \$\begingroup\$ @AJN Thanks for the help, I was missing that of adding the implicit 1 in the most significant part. \$\endgroup\$ Sep 3, 2020 at 2:44
  • 1
    \$\begingroup\$ Then this is an XY problem. Either you should be asking how to properly split the work so you don't have to do floating point math in an ISR, or you should be telling us what processor you're using and asking how to properly use the FPU inside an ISR. \$\endgroup\$
    – TimWescott
    Sep 3, 2020 at 2:51

1 Answer 1

6
\$\begingroup\$

Wikipedia has a nice page on the floating point format (the various IEEE-754 ones).

0x41100000

0b010000010001000000....

0 10000010 001000000....

Implied 1

0 10000010 1.001000000....

0x82 = 130

0 130 1.0010000

sign bit is zero so positive number

2 to the exponent 130-127 = 2 to the power 3.

So we move the "decimal" (binary) point over 3

1.001000000....
10.01000000....
100.1000000....
1001.000000....

so

0x41100000

is 1001.00000......

which is 9.0

Quite simple when you look at the format (for normal encodings):

(-1)^sign x 2^(exponent-127) x 1.fraction
\$\endgroup\$
1
  • \$\begingroup\$ and remember independent of base the least significant whole number is base to the power 0 (the 1s column) the next up is base to the power 2 and so on. works the same way to the right of the point, base to the power -1, -2 and so on so the first bit to the right is 1/2 the next 1/4 and so on, if you chop off three of those and divide by 8 you get that accuracy of that fraction. (in this case it was all zeros) if it were 0.1101 you could take one and call it 1/2 take two and call it 3/4ths take three and estimate it as 6/8ths and so on. If you need the fraction in some form. \$\endgroup\$
    – old_timer
    Sep 3, 2020 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.