Detecting compile-time versus run-time incompatibilities in powerPC

[Till Straumann]

I don't think it is a good idea.

If you introduce such tests (and in the past there have been many
which we have tried to eliminate) then it will become much
harder to ensure that the source even compiles cleanly for all
sensible combinations of CPP symbols.

Plus, some people might be tempted to introduce multilib variants
for all such combinations which is IMHO a wrong approach which
leads to rapid growth.

In my opinion the vast majority of code should be built with
generic PPC integer instructions (using appropriate gcc settings
to make sure only the common subset is emitted).

Then, there could be 2-3 multilibs for different FP architectures
(altivec, classic FPU, e500 gprs-float) and that's IT (for C-code
at least).
 
Special code (i.e., low-level system code that's written in assembly
anyways because gcc doesn't know about special registers and
instructions) should IMO use run-time feature detection or use
CPU-specific libraries where CPU-specific implementations reside.
(I'd not call these 'multilibs' since multilibs require ALL code
to be compiled for a specific CPU instruction set and/or ABI).
The application then uses
    appropriate multilib variant of most stuff
    cpu-feature specific CPU library

I certainly have strong feelings against having such #ifdefs
inside cpukit.

-- Till


Peter Dufault wrote:
> A few registers and programming modes have snuck into the MPC55XXEVB code that aren't supported on the MPC5554.  I'm working this out with Thomas, but I have a general question.
>
> With the number of different variants of the embedded powerPC family and what they support it's difficult to know what can be used across the board.
>
> It is nice to have a single binary that supports multiple platforms, but it's also nice to detect problems clearly at compile time, and the headers are a good place to keep track of these incompatible differences.  I'd like to undefine unsupported registers and modes in the headers so that compile fails.  This will not play well with a generic binary that uses run-time code to handle differences.
>
> What's the general consensus on this?   Are feature test macros worth-while, e.g., such as:
>
> #if (MPC55XX_CHIP_TYPE == 5554) && \
>   defined(DONT_DEFINE_UNSUPPORTED_REGISTERS_AND_MODES) && \
>   !defined(THIS_IS_GENERIC_CODE_AND_I_READ_THINGS_REAL_CAREFULLY_DEFINE_ALL_REGISTERS)
>           /* ALTCADR is reserved on the MPC5554 and writes will cause an exception.
>            */
>             uint32_t altcadr_reserved;
> #else
>             uint32_t altcadr;
> #endif
>
> Til, I expect you'll have thoughts
>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>