Re: [sdcc-devel] proposal for regression test changes

[Philipp K. K. <pk...@sp...>]

Am 20.12.25 um 23:20 schrieb Gabriele Gorla via sdcc-devel:
> currently many tests have per port overrides like:
> 
> #if !defined( __SDCC_pdk13) && !defined( __SDCC_pdk14) // Lack of memory
> #if !defined(__SDCC_ds390) && !defined(__SDCC_ds390) && !defined(__SDCC_hc08) && !defined(__SDCC_s08) && !defined(__SDCC_mos6502) && !defined(__SDCC_mos65c02) // struct return not yet supported
> 
> this is all over the place and it is really difficult to maintain.
> i.e. I have implemented struct return for mos6502 but I am still grepping the test suite to enable the relevant tests for the arch.
> 
> I am thinking to have each port define its features/limits in testfwk.h
> i.e. memory size, stack size, struct return, struct param, Bitint ...
> 
> In this way the tests would be able to check if they should run in a architecture independent way.
> 
> Any feedback?

Historically, we had such a macro for long long support, but now all 
ports (except unmaintained pic) support long long.
I think we'll get struct return working for all ports (except the 
unmaintained pic) next year.
For _BitInt, we do have BITINT_MAXWIDTH / __SDCC_BITINT_MAXWIDTH.
For memory, it gets more complicated. We know how many bytes (RAM and 
flash or (P)ROM) the target hardrdware has, but we don't know how many 
bytes the test will need, as the latter depends on how well SDCC (and 
the particular port) optimizes.

What other features are there that we might want to test for? Maybe a 
macro for __far in generic vs. generic in __far vs. neither one vs. no 
__far at all could be helpful?

Philipp