[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 <ralf.corsepius@rtems.org> writes:
[...]


m505;@mcpu=505@mrelocatable-lib@mno-eabi@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...

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 testing overlap.


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.

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.


Till


Regards,

David Querbach
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