[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: powerpc-rtems-4.7-gcc-4.0 patch commited
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
If a 555 variant has been added in newer versions of gcc, I'd like a
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
-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
Note that a #ifdef __mpcXXX in a BSP is *not* a valid reason as the
switch could go into bsp_specs. A run-time check for CPU type is even
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.
Real-Time Systems Inc.
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985