Detecting compile-time versus run-time incompatibilities in powerPC
dufault at hda.com
Mon Apr 12 16:57:33 UTC 2010
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
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.
HD Associates, Inc. Software and System Engineering
More information about the users