If I hadn't studied floating point from here my answer would be fraction bits of 000…000 and exponent value of −1 as shown below : 
But in the link I attached above, they mention Denormalized value in which case my answer for this question would be fraction bits of 100…000 and exponent value of 0. I know I'm mixing something up, and the second answer is probably wrong. Can somebody please clarify why it can't be denormalised value?
Electrical – The decimal value 0.5 in IEEE single precision floating point representation
floating point
Related Solutions
IEEE 754 floating point numbers are represented as a sign, a mantissa and an exponent.
It is possible to work with floats at a bit level, but you need to know what you're doing.
Here are some documents which explain further.
Both of the two answers (JRE and Spehro Pefhany) are okay except IEEE floating point has an extra feature.
I hope it is clear that
2.3 x 10^2 = 23 x 10^1 = 230 x 10^0
It would create more work for the hardware if all three were valid (translated into base 2). For example two different bit patterns could be the same number.
So, IEEE mandates that the top bit of the mantissa is always 1. This is a normalised representation. Each number is only ever stored as one specific bit pattern.
Then, because the first bit is always 1, it is not stored. So the mantissa is actually 1 bit longer than stored because of this implied top 1 bit.
Related Topic
- Electronic – TMS320 Floating Point (Texas Instruments DSP from ’98)
- Electronic – How does the ARM Compiler (Version 5) handle double-precision floats in devices whose floating-point unit hardware only supports single precision
- Electronic – How to convert single precision floating point numbers in a file into their 32 bit representation in VHDL
- Electronic – How we got exponent as \$2^{127-64}\$
Best Answer
Start with the number you have as \$v\$ and the number of mantissa bits available in the format as \$m=23\$ (for this format.) Assuming that \$v\ne 0\$, apply the following logic:
At this point, you have a value \$v : 2^m\le v\lt 2^{m+1}\$. The magnitude of your original number is now represented as \$v\cdot 2^p\$. But rounding hasn't yet occurred.
To round the value so that it fits within the IEEE 32-bit format, do the following step:
You now have the sign field represented as \$\left(s\right)\$, the mantissa field represented by \$\left(v-2^m\right)\$ (hidden bit notation), and the exponent represented as \$\left(m+p+127\right)\$.
At this point, there is a final step about finding out if the exponent is representable or instead out of range. If \$0\lt \left(m+p+127\right)\lt 255\$ (for single precision), then you are fine. But if that isn't true, then in the case where \$\left(m+p+127\right)\le 0\$ you may be able to consider adapting it to a denormal format where you can preserve some, but not all, of the higher order mantissa precision bits. (A denormal sets the exponent field arbitrarily to zero.) In the other case where \$\left(m+p+127\right)\ge 255\$, you cannot represent the number in the format and you need to select an error format code, instead. These special values all set the exponent field to 255 and encode special, added meaning inside the mantissa field.
One thing that many fail to understand is the concept of the hidden bit notation. It's not complicated, but it takes a moment to consider.
Since the mantissa is normalized before packing, it's always the case that the upper-most bit is a 1 (unless the value was 0, of course.) So it's a waste of space to include it. As a result, the upper-most bit is removed (hidden) and only the remaining bits are packed into the mantissa. (It is also restored when unpacking the floating point format, too.) You can see the fact that I hide it in the above discussion where I wrote \$\left(v-2^m\right)\$: the \$-2^m\$ term is where I'm removing the hidden/upper-most bit of the mantissa.
In the case of denormals, the hidden bit isn't hidden but is instead included into the mantissa field since the exponent (excess 127 format) is always zero in this case and it isn't otherwise possible to "restore" a hidden bit since there is no information about where to put it in the case of a denormal.