[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: powerpc-rtems-4.7-gcc-4.0 patch commited
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 <email@example.com> writes:
> >>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
Right, most of powerpc multilib variants inside of GCC use the same ISA,
but use different optimization strategies/costs, overall resulting in
> 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
> Note that a #ifdef __mpcXXX in a BSP is *not* a valid reason as the
> respective compiler
> The only (legacy) reason I can think of are #ifdef __mpcXXX in cpukit
> and/or libcpu - however,
> these should be cleaned up.
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.