Re: [hatari-devel] FPU update

Am 26.01.2017 um 18:39 schrieb Toni Wilen <twilen@xxxxxxxxxx>:

Quick test results:

FMOVEM does not do anything (as documented), FMOVEM to register
and FMOVEM from same register back to memory: same bit pattern.

Any arithmetic operation seems to normalize it automatically. I
tried FNEG, FABS, FADD (with another register containing zero),
register content was normalized even if it was source for FADD.

Thank you for the quick test! In this case I need to add that
automatic normalization to fp_arithmetic. I guess 68040/68060 will
raise unimplemented datatype (pre) exception. That would make sense,
wouldn't it?

Yeah, which is already supported in get_fp_value() (for source values).

I guess cleanest way is to replace "fault_if_unimplemented_680x0" before
arithmetic call with function that does first unimplemented check and
then normalizations if neeeded.

I already realized that this needs to be checked in a single place before fp_arithmetic. The problem is that if i add this check directly before calling fp_arithmetic it will override fpu_noinst, if an invalid arithmetic operation is called (default in fp_arithmetic switch).

I'm afraid that fault_if_unimplemented_6888x and 680x0 need to be changed to explicitly check for implemented instructions and fail on all other cases. Then no unimplemented instruction can reach fp_arithmetic and we can just do our denormal/unnormal check before calling fp_arithmetic or inside fp_arithmetic. Less elegant than before, but i have no better idea at the moment.

btw for 68040 we also need to check if this is handled correctly:

When the processor encounters an unsupported data type. the procedure taken is identical to that used when an unimplemented instruction is taken. Unsupported data types with operands that have opclass 010 or 000 (register-to-register or memory-to- register) instructions cause a pre-instruction exception. When an unsupported data type is detected for opclass 011 (register-to-memory) instructions. a post-instruction exception is generated immediately. A format $0 (for the pre-instruction exception) or format $3 (for the post-instruction exception) stack frame is saved. and vector number 55 is fetched. A denormalized value generated as the result of a floating-point operation generates a nonmaskable underflow exception instead of an unsupported data type exception.