powerpc-rtems-4.7-gcc-4.0 patch commited

[Till Straumann]

Ralf Corsepius wrote:

>On Thu, 2005-02-17 at 08:27 -0800, Till Straumann wrote:
>  
>
>>Hi Ralf
>>
>>Ralf Corsepius wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>FYI: I have committed my powerpc RTEMS-gcc multilib patches to GCC's CVS
>>>trunk (aka. GCC-4.0).
>>>
>>>This patch introduces a completely new layout of powerpc multilibs:
>>>
>>># powerpc-rtems4.7-gcc --print-multi-lib
>>>.;@mrelocatable-lib at mno-eabi@mstrict-align
>>>m403;@mcpu=403 at mrelocatable-lib@mno-eabi at mstrict-align
>>>m505;@mcpu=505 at mrelocatable-lib@mno-eabi at mstrict-align
>>>m601;@mcpu=601 at mrelocatable-lib@mno-eabi at mstrict-align
>>>m603e;@mcpu=603e at mrelocatable-lib@mno-eabi at mstrict-align
>>>m604;@mcpu=604 at mrelocatable-lib@mno-eabi at mstrict-align
>>>
>>>      
>>>
>>Why do we need a m604 (and possibly more CPU variants)?
>>    
>>
>There is a BSP in CVS which uses the m604.
>  
>
??? I guess I said this before, but code generated for mcpu=powerpc 
executes on
*any* integer PPC cpu. If the BSP checks for #ifdef mpc604 [I cant' 
think of a reason
since the code in 'shared' does run-time detection of the relevant 
features] it would
be enough to add -mcpu=604 to the BSP's CFLAGS.

Sorry, but I think there's still way too much bloat...


>  
>
>> I thought
>>the #ifdefs testing for a CPU type in RTEMS have been cleaned up?
>>    
>>
>They have been massively cleaned up, but there still remains a lot of
>arkwardness :(
>  
>
I can believe that :-(

>  
>
>>>m860;@mcpu=860 at mrelocatable-lib@mno-eabi at mstrict-align
>>>m7400;@mcpu=7400 at mrelocatable-lib@mno-eabi at mstrict-align
>>>
>>>      
>>>
>>I don't see the altivec options here - I guess --print-multi-lib doesn't 
>>show all the active options?
>>    
>>
>-mcpu=7400 implies -maltivec
>
does it also imply mabi=altivec? Note that this is crucial since it 
enforces the correct
stack alignment. For altivec to work properly, ALL code must be 
generated -mabi=altivec
otherwise, the altivec register save area on the stack is not properly 
aligned.

>
>-mcpu=7450 is "multlib"-matched to -mcpu=7400, i.e. uses the same
>multilibs as -mcpu=7400
>
good.

>
>  
>
>>>nof;@msoft-float at mrelocatable-lib@mno-eabi at mstrict-align
>>>m601/nof;@mcpu=601 at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
>>>m603e/mpc8260;@mcpu=603e at Dmpc8260@mrelocatable-lib at mno-eabi@mstrict-align
>>>m603e/nof;@mcpu=603e at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
>>>m603e/mpc8260/nof;@mcpu=603e at Dmpc8260@msoft-float at mrelocatable-lib@mno-eabi at mstrict-align
>>>m604/nof;@mcpu=604 at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
>>>m7400/nof;@mcpu=7400 at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
>>>
>>>      
>>>
>>I definitively don't see the point of having a 604 and 7400 soft float 
>>variant.
>>    
>>
>Convenience - You don't want to/don't need a necessity to test your BSPs
>with FPU disabled? I think this is necessary and convenient when
>developing BSPs.
>
The other way round - I found problematic areas in newlib by using the 
'hard-float' variant
in combination with a disabled FPU. This way, I find buggy tasks that 
claim to be 'integer-only'.
I can't think of a situation where soft-float would be useful.

Don't get me wrong - I'm not barfing, I just try to keep variants to a 
minimum which
at the end of the day should make your life easier...

T.

>
>Ralf
>
>
>
>  
>