Re: [hatari-devel] FPU update

[Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>]

Am 25.01.2017 um 22:43 schrieb Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>:

> 
> Am 25.01.2017 um 20:24 schrieb Toni Wilen <twilen@xxxxxxxxxx>:
> 
>>>   Did the tests also change? Now it lists huge amount of failed tests
>>>   compared to previous version. Previously neg/abs test was first that
>>>   failed.
>>> 
>>> 
>>> No but the errors are now reported with much finer resolution -
>>> previously an error would be reported at the end of a full test, if the
>>> combined hash was incorrect. Now it reports an error on each individual
>>> result word that is incorrect - hundreds of times more reports
>>> (potentially). It also reports the result words (and expected values) as
>>> hex when they are not a match.
>> 
>> Results are same, first passed tests just scrolled so quickly that I
>> thought they caused the errors.
>> 
>> This update fixed fabs (and fneg) tests:
>> 
>> static void fp_abs(fpdata *a, fpdata *dst)
>> {
>> 	if (floatx80_invalid_encoding(a->fpx)) {
>> 		float_raise(float_flag_invalid, &fs);
>> 		dst->fpx = floatx80_default_nan(&fs);
>> 		return;
>> 	}
>> 	uint64_t aSig = extractFloatx80Frac(a->fpx);
>> 	int32_t aExp = extractFloatx80Exp(a->fpx);
>> 	if (aExp == 0x7FFF && (uint64_t)(aSig << 1)) {
>> 		dst->fpx = propagateFloatx80NaN(a->fpx, a->fpx, &fs);
>> 		return;
>> 	}
>> 	dst->fpx = floatx80_abs(a->fpx);
>> }
>> 
>> btw, fabs/fneg test never triggers floatx80_invalid_encoding() check.
>> 
>> fsgldiv/fsglmul still is incorrect but I'll wait for pause when error
>> option first.
>> 
> btw: floatx80_invalid_encoding is not necessary. It only detects unnormals. This is handled in fpp.c by automatically normalizing unnormals (6888x) or raising an exception (68040/68060). If floatx80_invalid_encoding would trigger with any function that would mean i made a mistake in fpp.c.
> 
A question has raised while checking if all unnormals are caught before used for calculation:
Theoretically it is possible to write an unnormal number to an FP register using FMOVEM. Then using that register as source (or destination for dyadic operations) will input an unnormal value to the arithmetic operation. At least that currently happens in emulation. I wonder how this is handled by real hardware. Does anybody know?

It could be tested by moving an unnormal number like: 0x40000000 0x08000000 0x00000000 to a register using FMOVEM and then applying some arithmetic operation (e.g. FADD) on it with the second operand being a normal number like 0x40000000 0x80000000 0x00000000. Furthermore it would be interesting if it makes a difference if the source or destination operand, or both operands are unnormal. In addition to the result it would be interesting if any exception bit is set (most likely operand error).