|Re: [hatari-devel] Basic cpu testsuite|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On Sonntag, 29. April 2018 20:10:21 CEST Eero Tamminen wrote:
> Strange how?
> Vasm is supposed to support "standard" ELF,
Yes, that's a good thing. What i find "strange" is the way to write inline
asm. And for short statements like in the tests, i prefer that, even if the
inline asm of gcc is also not so easy to read sometimes. But putting them in
separate files has the drawback that the syntax will still be assembler
dependent (hex constants are different, comments are different, passing
parameters is compiler dependent etc.) And it is more work to write the rules
to put it all together.
>I think its FPU emulation has still some advantages over Hatari
Aranym does not have a gemdos emulation like Hatari (it relies on MiNT to be
able to access the host filesystem), so i cannot yet run the tests there, but
i would bet that at least the FPU related tests will have similar, small
errors as the ones in hatari when using the native FPU emulation. Maybe MPFR
comes close, but i would bet that there are also small differences. Not that
it makes much difference in practise, as long as some program does not rely on
real bitwise exact values (which is quite unlikely, given that most compilers
will use a 64bit double anyway, not the format used internally by the FPU),
but of course it is not an exact emulation of the FPU.
>What kind of tests should be done for instructions?
>Is there some way to auto-generate them?
Hm, that will be difficult. Maybe you can come with something that reads the
table68k, then generates one instruction for each combination of allowed
addressing modes. The question is where such code should get its input values
from, and how to verify the results.
Also, if you look at the tests, you may notice that they currently also try to
test some corner cases that might not even be relevant for "real" programs.