Detecting compile-time versus run-time incompatibilities in powerPC

[Peter Dufault]

On Apr 12, 2010, at 12:33 , Till Straumann wrote:

> First of all, IMO the only register definitions, access macros etc.
> that should be in cpukit headers are such that are reflecting the
> multilib variants (i.e., describe features that are 'known' to gcc
> also).
What we have here is a failure to communicate.  I didn't provide enough context.  I'm not talking about multilib stuff, I'm talking about RTEMS BSP options and modifying existing code in a way that is consistent with how it's written now but looks forward.

These headers aren't in cpukit, they're in c/src/lib/libcpu and c/src/lib/libbsp.  I am interested in much of what you wrote, since I'm using the SPE which generates __SPE__ and which could justify a multilib variant so that all code is built in an SPE-aware manner, but that isn't what I'm after right now, I'm happy using the SPE as a peripheral.  This is about modifying existing headers.

...

> 
> Now, if you want to introduce such macros in 'libcpu' and/or 'libbsp' then
> I have less strong objections. I still think as much code as possible should
> use run-time detection or at least a cpu specific library but you could
> use conditionals but in NO case should the symbol that defines the CPU
> you want to compile for be defined by gcc/cpp/multilibs. The correct
> way would be using 'configure' for that purpose.

Yes, that's what I'm doing.
> 
> You would 'configure' libcpu for a specific target cpu and let configure
> produce appropriate variants of headers etc.

Yes, that's what's being done.

> 
> -- Till
> 
> PS: I have two comments regarding your code example below:
> 
> 1) It would obviously be easy to handle the examples below at run-time
>   -- provided that there is a 'cpuid' register of some sort, of course.

I'll let someone trying to run RTEMS strictly out of the on-chip FLASH and RAM of some of the MPC55XX's discuss this.
> 
> 2) IMHO it is bad programming practice to access registers just
>   as ordinary memory. I would always use dedicated I/O operations
>   for sake of readability and to ensure/enforce ordering.
> 

When modifying existing code I slavishly follow existing code practice unless advocating a whole-sale change.  FYI I agree.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering