> On Sep 17, 2018, at 5:25 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 17 September 2018 at 22:18, John Arbuckle <programmingk...@gmail.com> > wrote: >> https://www.nxp.com/files-static/product/doc/MPCFPE32B.pdf >> Page 2-8 in table 2-4 is where the description of this bit can be found. >> >> It is described as: >> >> Floating-point fraction rounded. The last arithmetic, rounding, or >> conversion instruction incremented the fraction. This bit is NOT sticky. >> >> This patch actually implements the setting and unsetting of this bit. >> >> Signed-off-by: John Arbuckle <programmingk...@gmail.com> >> --- >> fpu/softfloat.c | 12 ++++++++++-- >> include/fpu/softfloat-types.h | 1 + >> target/ppc/fpu_helper.c | 12 ++++++++++++ >> 3 files changed, 23 insertions(+), 2 deletions(-) >> >> diff --git a/fpu/softfloat.c b/fpu/softfloat.c >> index 59ca356d0e..c5378ae9e8 100644 >> --- a/fpu/softfloat.c >> +++ b/fpu/softfloat.c >> @@ -751,9 +751,17 @@ float64 __attribute__((flatten)) float64_add(float64 a, >> float64 b, >> { >> FloatParts pa = float64_unpack_canonical(a, status); >> FloatParts pb = float64_unpack_canonical(b, status); >> - FloatParts pr = addsub_floats(pa, pb, false, status); >> + FloatParts intermediate_parts = addsub_floats(pa, pb, false, status); >> >> - return float64_round_pack_canonical(pr, status); >> + float64 rounded_result = >> float64_round_pack_canonical(intermediate_parts, >> + status); >> + FloatParts rounded_parts = float64_unpack_canonical(rounded_result, >> status); >> + >> + if (rounded_parts.frac != intermediate_parts.frac) { >> + float_raise(float_flag_round, status); >> + } >> + >> + return rounded_result; >> } > > Only changing the add instruction looks very definitely wrong. > Doing a pack-unpack-compare looks dubious.
Now that I think about it I see it could be done differently (more efficiently). > I think that you can do this by using the existing overflow and > inexact flags. I'm not sure how I would do this. Do you think they are mutually exclusive? > If that is not possible (but I'm pretty sure it should > be doable), then the next best approach is probably to have the new > float flag be set at the right point in the round-and-pack code. This sounds like a good idea. The round_canonical() function is where I would place such code. This function is used by several arithmetic instructions so it might be able to more than just the add function. Thank you for reviewing my patch.
