| Re: [hatari-devel] Basic cpu testsuite |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 04/28/2018 11:33 AM, Thomas Huth wrote:
Am Sat, 28 Apr 2018 09:20:20 +0200
schrieb Thorsten Otto <admin@xxxxxxxxxxx>:
On Samstag, 28. April 2018 08:53:30 CEST Thomas Huth wrote:
Sorry, but I did not see any patch attached to that mail.
The patch was in the archive ;) Ok, a bit confusing, so just again.
Ah, well, now I got it. My eyes apparently ignored the file with the
funny filename "6967:41f2e8a1ac81.txt". Sorry for the confusion.
The archive now also contains the whole tests/cpu directory. The
patch is in a separate attachment. The only difference is that the
patch also has 2 small changes, to .hgignore and tests/CMakeLists.txt.
Ok, that's a big patch ... give me some time to digest it, please.
Some quick questions after having a first glance:
- Did you write all the code on your own? Or does this include some
third party code? Can all be licensed under the terms of the GPL?
- In case we decide to put the corresponding binaries into the
repository (since not everybody has the cross compiler installed),
IMHO the CMake changes for compiling the binaries could be skipped.
Rest of the tests aren't built as part of Hatari build process either.
There's just source code & make files for building them separately
(I'm building them "natively" under Hatari or Aranym).
would it be feasible to merge the many tests into fewer PRGs?
E.g. one PRG for testing integer arithmetics, one for floating
point arithmetics, etc. Otherwise the overhead of the libc stuff
that is linked into each PRG is too big compared to the real test
code.
- Now we got some code that needs TurboAss, some code that needs
AHCC, and with this some code that needs m68k-atari-mint-gcc ...
I really think we need to standardize on one tool, otherwise this
will get too messy in the long run...
My tests that are compiled with AHCC (NatFeats), support also
other compilers (VBCC and GCC). AHCC seemed just easiest, because
its default libc produces small binaries as-is.
- Stuff like the "move sr,d0" vs. "move ccr,d0" ifdeffery of course
won't work if the binary should be used for both, 68000 and 68010+
CPU levels. We'd need to think of a way to solve that before such
a test could be included...
- Eero