|Re: [hatari-devel] FPU rounding|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On sunnuntai 09 marraskuu 2014, Nicolas Pomarède wrote:
> Le 09/11/2014 21:52, Douglas Little a écrit :
> > I think I may have reported this before, but ran into it again today.
> > Hatari's WinUAE appears to be ignoring the 68881's precision and
> > rounding control bits.
Are you using FPUCW 80 bits mode?
> > These bits determine nearest or chop rounding, which are quite
> > important when trying to convert to/from fixedpoint values.
> > This causes small negative numbers (e.g. -0.0001) to round to zero when
> > the integer part is extracted, and when subtracted and scaled to
> > extract the fraction in fixed point form, it produces a negative
> > value. This generates an invalid fixedpoint value (integer & fraction
> > differently signed) in my code.
> > It can be worked around by using a carefully chosen bias during
> > conversion, and configuring round-to-nearest (which is what it seems to
> > be doing regardless of FPCR) but this wasteful, and only works for an
> > expected range anyway.
> > I guess this is a UAE thing not a Hatari thing, but it would be good if
> > somebody can check and decide if this can be fixed?
There was short discussion on this 2013 summer under
"m68k FPU precision issue" subject. Only conclusion was
that neither of our current cores supported all precision
modes and nobody knew any game/demo needing better precision.
Aranym had same issue, and it caused problems for Debian
m68-Linux where this issue was originally noticed.
> I haven't checked this, but as a new winuae cpu core should be available
> soon, I think it's better to check this when it's available, instead of
> investigating the current/older winuae's core. It's quite possible it's
> already fixed in this new version.