powerpc-rtems-4.7-gcc-4.0 patch commited

Till Straumann strauman at slac.stanford.edu
Thu Feb 17 21:52:58 UTC 2005


David Querbach wrote:

>On Thu, Feb 17, 2005 at 09:00:51PM +0300, Sergei Organov wrote:
>
>  
>
>>Ralf Corsepius <ralf.corsepius at rtems.org> writes:
>>[...]
>>    
>>
>>>m505;@mcpu=505 at mrelocatable-lib@mno-eabi at mstrict-align
>>>      
>>>
>>To further qualify the current situation. There is mpc5xx CPU support in
>>the tree that has nothing to do with mpc505/mpc509. Instead it targets
>>mpc555 (and maybe mpc565 and mpc566) that are quite different from
>>505/509. If this multilib variant is supposed to support this mpc5xx
>>port, I think it should use another name and mcpu= target.
>>
>>Well, in fact I don't think there will be any difference in compiled
>>code if you change mcpu=505 to mcpu=555 as both seem to share the same
>>core. Anyway, the target is confusing.
>>    
>>
>
>The ss555 BSP uses -mcpu=505, because as far as I can tell, it's the most
>appropriate gcc cpu variant for the MPC555.  From what I can see in the
>source for gcc (up to 3.4.1), there is no other -mcpu=5xx variant available.
>
>If a 555 variant has been added in newer versions of gcc, I'd like a chance
>to test it before the m505 multilib disappears.
>
Why do you think you need mcpu=xxx other than powerpc ?

It's amazing: until now, nobody has come up with a good reason for 
creating any
-mcpu=xxx variant and yet there are still way too many...

Note that a #ifdef __mpcXXX in a BSP is *not* a valid reason as the 
respective compiler
switch could go into bsp_specs. A run-time check for CPU type is even 
better.

The only (legacy) reason I can think of are #ifdef __mpcXXX in cpukit 
and/or libcpu - however,
these should be cleaned up.

Till

>
>Regards,
>
>David Querbach
>Real-Time Systems Inc.
>  
>





More information about the users mailing list