powerpc-rtems-4.7-gcc-4.0 patch commited

[Joel Sherrill <joel@OARcorp.com>]

Till Straumann wrote:
> 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...

Agreed.  Trying to keep them to a bare minimum is the goal because it 
simplifies building, testing, etc.  We could end up where most PPC users 
are actually using the same binary code for RTEMS which increases 
testing overlap.

> 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.

If possible and not leading to bloat.  Balance is the key to life.

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

Technically they are allowed in libcpu so you can be aware of on-cpu 
peripherals, cache particulars, etc.

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


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985