powerpc-rtems-4.7-gcc-4.0 patch commited

[Ralf Corsepius]

On Thu, 2005-02-17 at 13:52 -0800, 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 ?

The current layout/design is a compromise between
* code optimization
* toolchain size
* history.

Right, most of powerpc multilib variants inside of GCC use the same ISA,
but use different optimization strategies/costs, overall resulting in
different code.

> It's amazing: until now, nobody has come up with a good reason for 
> creating any -mcpu=xxx

Then let me give some:
* Different ISAs in GCC.

* Conditional code (ASM/ifdef'ed C) in libgcc, newlib, cpukit.
Until recently, cpukit was cluttered with a large amount of such code.
Meanwhile, the situation has somewhat improved, but there is still a lot
of room left for improvement.

* Extensions for a particular cpu-variant in GCC.
E.g. in older GCC's, you didn't have -maltivec, so you'd have to resort
to another cpu-variant/ISA. 
 Apparently "not using altivec" wasn't an acceptable compromise to you.
Now, all other powerpc users will have to accept an altivec variant.

>  variant and yet there are still way too many...
Yes, but ... a large part the cause of these problems is inside of RTEMS.

E.g. the m8260 would be superflous, if it could be removed from cpukit.
The code it uses is _identical_ to the 603e, except of 1 define in
cpukit.

> Note that a #ifdef __mpcXXX in a BSP is *not* a valid reason as the 
> respective compiler
Right.

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

Eg. let's implement a common API, shared between old and new exception
processing. Lack of this is the cause for at least 3 multilib variants.

Ralf