# Do we need to check for mantissa overflow in floating point multiplication?

We do check for the mantisas overflow in floating point addition

e.g.

If we are adding $$8.02 \times 10^3 + 9.01 \times 10^3 =17.03 \times 10^3$$ i.e we get an overflow, so we shift the number right and increase the value of exponent.

But does it occurs during floating point multiplication?

According to my logic, it should occur. because $$9.99\times9.99=99.80$$ which is a mantissa overflow, but that's not the case.

I have referred to Morris Mano's books and William Wtallings Computer Organization and Architecture book but none of those books mentioned about floating-point multiplication mantissa overflow.

So I feel like I am wrong.

Please tell me where I am wrong?

• Jan 23 '20 at 16:12

When we multiply, the answer is stored in 2 registers. When we multiply 2 numbers the results length does not exceed ($$n_1+n_2$$) where $$n_1$$ is length of 1st number and $$n_2$$ is length of second number. So there is no chance of overflow here as the length of 2 registers is greater than or equal to $$n_1+n_2$$.

• Welcome to COMPUTER SCIENCE @SE. I remember implementations of integer multiplication matching this description. What if the result is to occupy a single "cell"/ register? Does denormalisation/mantissa overflow occur during floating point multiplication? How much of a problem is it? Oct 18 '20 at 6:50

You are both wrong and right.

The wrong part is that floating point numbers are stored binary in computers of today. Your example is in decimal.

You are right in that what call mantissa overflow actually happens. Before the return to user program however the FPU does a renormalization. There are a few odd cases of course. You might want to read up on ieee 754 standard.

• ok. i will take an example in binary. 1.11*1.11=11.001 which is a case of overflow many sources that i studied neglect this multiplication algorithm by saying that the multiplication is same as in case of fixed point numbers i think that is the only logic that can make no overflow in floating pt no.s true as in multiplication we neglect the extra bit and just write our answer within the bits that we take for Accumulator and Q register. Jan 23 '20 at 17:13
• if we took A=4 bit and Q=4 bit...and get more than 4 bits, we will neglect that bit in multiplication of fixed point algorithm(i guess as it was the case for booth's algorithm) Jan 23 '20 at 17:17
• If I would program a floating point multiplication this is probably how I would do it. Using 9.99 x 9.99 I would start by normalizing between 0 and 1. The multiplication would then be 0.99 x 10 x 0.99 x 10. The exponent I would handle separately. The multiplication of 0.99 x 0.99 clearly stays below 1, so no overflow there. The result would be 0.998 x 100.’ Jan 24 '20 at 7:58
• Reading through the section in Stallings’ book, I think it makes the hidden assumption that numbers are adjusted as @ghelquist suggests, but then the boundary case for early exponent overflow also needs to be adjusted, so it’s not clear. Feb 24 '20 at 15:29

Compare $$(9.99 \cdot 10^2) \cdot (9.99 \cdot 10^3) = 9.98001 \cdot 10^6$$ and $$(1.01 \cdot 10^2) \cdot (1.01 \cdot 10^3) = 1.0201 \cdot 10^5$$. One has a higher exponent than the other.

So in base 10, you'd check if the product of the two mantissas is ≥ 10, and in this case move the decimal point to the left (99.8001 becomes 9.98001) and increase the exponent. Same in base 2, where you'd need to check if the product of the mantissas is ≥ 2 or not.

PS. We could obviously in base b require not that 1 <= m < b, where m is the mantissa, but that 1/b <= m < 1. In that case overflow is impossible but we need to check for underflow.