| Re: [hatari-devel] Basic cpu testsuite |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 04/29/2018 04:54 PM, Thorsten Otto wrote:
On Sonntag, 29. April 2018 15:41:37 CEST Eero Tamminen wrote:
IMHO the CMake changes for compiling the binaries could be skipped.
There might be some better way to add the targets so they only get compiled
when doing "make test", i just couldn't figure it out. But the rules should be
there, because specific tests may need specific compiler flags.
There of course should be *exact* build instructions/files, I was just
saying that it doesn't necessary need to be cross-compilation one or
integrated to CMake.
My tests that are compiled with AHCC (NatFeats), support also
other compilers (VBCC and GCC).
But vbcc and ahcc don't support cross compilation.
Unlike recent versions of GCC, they work fine with TOS and are small
enough to run on ST. Them working fine under Hatari as-is (not
needing MiNT setup) makes them independent from the host build
environment.
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
cross-compiler.
(AHCC doesn't really optimize anything, so it's fast.)
Also, i don't think it makes sense to write the assembler statements
for testing the cpu emulation for lots of different compilers.
Absolutely agree.
I makes sense only when they're provided as examples for end users
(like NatFeats tests are).
because its default libc produces small binaries as-is.
That's why i added libcmini. The produced binaries should not be substantial
larger than the ones of AHCC or PureC. Beside that, AHCC and its library are
extremely buggy.
Anything compared to GCC (or LLVM) is buggy. :-)
~5 years ago when I used them quite extensively, I found lots of bugs
in both AHCC & VBCC/Vasm, both with code generation and includes &
libraries, but I think Henk & Frank have fixed those by now.
Are the AHCC bugs you're referring to about code generation, or about
the includes & libraries? Hatari tests are minimal, so only code
generation issues should matter...
While AHCC 32-bit int support is still a mess, I think it should be
fine for test programs using 16-bit ints.
I think that all test code done in plain C should be generic enough
to work on multiple C compilers, so that if somebody wants to use
a different compiler, they just need few ifdefs and separate build
files.
There's already minimal startup code for AHCC, and you've provided
it for GCC+libcmini. I think those are enough. AHCC can be run
natively, and GCC can be used for cross-compilation.
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, and which C-compiler syntax of
that. Linker object ABIs are more portable.
For example, if code is written to be compatible to Devpac (native),
it can be assembled also with Vasm (cross-assembler), and linked
with GCC.
- Eero