|Re: [hatari-devel] FPU update|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] FPU update
- From: Douglas Little <doug694@xxxxxxxxxxxxxx>
- Date: Fri, 27 Jan 2017 11:58:34 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=w259UQE4EbK9vrYsKEmb9f0ETJn89CMGbTlQg9RRtto=; b=VYdyCuIxSeb4Kg9N0cGvvxHR0qJMcg7bDXw4PnwEyz8vV4k/1GS+c3G6u7d4zNUJLV wNuxFehXnlpnGt3duBD6+uEs1Xo8NrjnIxl3ht/yTEq2qwiG/UnXo1peGjUI2pHYJBQc qzwmODEuKgsvlZojkXbhWdEgDdicmlWc5ZiphVkL1GDTyHvhuhsogeyh851thkiglsX4 wRNboGYNkt5qAsUb3gDTImry++lXa2DCK0rpeT6SQK6wMSEVoNVROYLQ9ucFD1SzTWKQ zfiCV1YWTu2Kx5HvP200D4H5089cAGflfEGZM1O5872qoGZot7lP9Vo1fRptKkhXg4jB 18Kg==
Here is an intermediate update to the fpu tester from last night, incorporating some of the suggestions:
- opcode sequence is printed for failures
- operands are printed, for those cases where operands are not limited to immediate data (which can be found in the opcode sequence)
- prints a maximum of 64 errors per test before moving onto the next (otherwise it can spam for several minutes on one test)
- waits for a key after each unit test failure (but not each individual failure)
Caveat: since some tests - such as fadd/fsub - accumulate changes in one operand register, recording those operands before an instruction involves writing the register back to memory as a double. This might produce misleading results since conversion is involved when writing floats to memory. I didn't really want to complicate things further by adding extended/packed decimal code. so this is the best I can do for now! Best intercept the test at runtime to get the true state for any test operands which don't seem to make sense in the report....
I have not incorporated the FPSR testing yet but have done some work on it. I can't really do this without affecting the expectation data. When I make this change I'll also update the tests themselves to remove some issues I noticed (specifically the fadd/fsub test seems to saturate on some values and gets stuck for long periods outputting the same result). For now, the expectation data remains as it was before. Due to this, the expectations recording program (fpudrec.tos) hasn't even been reassembled, even if the source has changed....