|Re: [hatari-devel] Basic cpu testsuite|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On Sonntag, 29. April 2018 17:33:56 CEST Eero Tamminen wrote:
>I was just
>saying that it doesn't necessary need to be cross-compilation one or
>integrated to CMake.
But isn't that the purpose, of being able to say "make test", during the
> I write the code on host and have a small script that runs AHCC
> with Hatari. Build speed-wise it's "as fast" as using GCC
Hu? I can't believe that. Starting up Hatari alone takes at least several
seconds (not Hataris fault). In the same time, i can easily cross-compile
several hundreds of source files.
>Are the AHCC bugs you're referring to about code generation, or about
>the includes & libraries?
Both. When i last looked, it took me only a few minutes to spot ~20 bugs in
the library. Not really surprising, given that it is based on dlibs from the
early 80s. And to the code generation, to be honest i don't trust a developer
who thinks he can use the same library for both 16- and 32bit ints, by just
changing all header files to use short. Beside that, the ST version of the
compiler isn't able to handle double, not even softfloat.
I didn't consider vbcc, because the assembler interface is really strange
there, and you would have to write every test as a separate function.
>If test file is mostly assembly, I think it should be considered
>writing it completely in assembly, to avoid the issue of how to
>interface them to C source code,
But then you also have to write the whole library in asm, otherwise you again
have that problem of the interface. The idea was to have something where you
can just use printf for the expected/actual values, run that on real hardware,
and adjust the tests if necessary.