Re: [hatari-devel] FPU rounding

Quick update on this problem...

Frank Wille (of VASM/VBCC fame) did a little investigating for me and apart from confirming the FP rounding problem in UAE, he discovered that several versions of UAE behave quite differently from each other with respect to rounding..

It seems however that the most recent versions have fixed both FINT and FMOVE so they both now work correctly. I'm not sure if that includes WinUAE or just UAE but it sounds like the problem has at least been recognized and could make it into Hatari along with a new core at some point...

On 10 November 2014 12:05, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

Quick follow-up.... it appears that the 'FMOVE FPx,Dn' instruction is affected by this problem, but 'FINT FPx' is not.

So UAE is not completely ignoring the FPCR, it is just ignoring it when performing float-int moves to round and convert simultaneously.

The manual does state that the FPCR is observed when performing FMOVE so it is still a bug, but it looks like a more narrow case than I first though.

D.

On 10 November 2014 10:02, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

> > Hatari's WinUAE appears to be ignoring the 68881's precision and
> > rounding control bits.

Are you using FPUCW 80 bits mode?

It doesn't seem to matter which mode - the code I am testing shouldn't care about the precision part in fact - only the rounding mode. Changing the precision mode doesn't affect outcome. I assume it's just fixed/ignored within UAE.

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.

I think a more serious issue is how rounding is performed. It seems to be stuck on round-to-nearest or round-to-zero, I'm not sure which it is yet. But it is stuck on one or the other.

The problem I'm having is how to extract a 64-bit fixedpoint value, if only 32bit float->int moves are supported. Rounding must happen for the integer portion, and if it is wrong then the value will vary from slightly incorrect to completely corrupted (disagreement in sign).

I have started looking at other (maybe more robust) ways to do this which don't rely on FPCR and don't involve adding a bias and the side effects that causes - but I expect it will be more complex than planned.

D