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