[Libre-soc-dev] FPMUL32 rounding

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue Jun 8 13:21:32 BST 2021

crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Fri, Jun 4, 2021 at 3:05 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>

> On Fri, Jun 4, 2021 at 1:34 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>> I used the test case you have in that unit test, demonstrating that doing
>> the multiplication as f32 gives exactly the same answer as doing the
>> multiplication as f64 then rounding to f32 (this only works for some fp
>> ops):
>> See the fmuls_1 and fmuls_2 functions:
>> https://rust.godbolt.org/z/6asaf6Mq6 (note the dbgf! macro prints the
>> input
>> then returns it unmodified)
>> I also tested on a Power9 and it gives identical results.
ok i tracked it down.  the "broken" code uses the Load/Store SINGLE/DOUBLE
conversion back-to-back.  sounds perfectly reasonable: it's a FP32 in the
of an FP64, therefore truncate the result to FP32 then re-expand it to FP64,

wrongggg... this process of truncation, because it was calculated with
potential rounding, *ignores* the lower bits.

from the spec, p152, v3.0B;

are then added or subtracted as appropriate, depend-
ing on the signs of the operands, to form an intermedi-
ate sum.
*All 53 bits of the significand as well as all threeguard bits (G, R, and
X) enter into the computation.*

that's for *fadds* - not fadd.

interestingly, fmuls does not make a similar statement.  however,
clearly, when calculating FP32xFP32 the resultant mantissa
is at... errr... 24+24+guardbits, and if those bits are IGNORED
then we get the rounding problem.

i've just added this, which is the same pseudo-code for FRIN
(from Appendix A.1), it's currently incomplete:

and the problem has gone away.  Lauri as long as you do not
put in any numbers that overflow (which i do not believe there
are in any of the MP3 tests) the current pseudocode should
be sufficient.


More information about the Libre-soc-dev mailing list