[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ppc multlibs and BSP removal was Re: powerpc altivec support



Ralf Corsepius wrote:
On Wed, 2005-02-09 at 06:40 -0600, Joel Sherrill  wrote:

Ralf Corsepius wrote:

On Tue, 2005-02-08 at 20:44 -0800, Till Straumann wrote:


Ralf Corsepius wrote:



On Tue, 2005-02-08 at 15:52 -0800, Till Straumann wrote:


  + m821 and m860 -- these are equivalent and equal "mppc".  Mapping
    both to another multilib and kill.
  + All 601 and 602 variants should be dead.  Can someone comment.
  + Can mpc8260 should be mapped to a 603e variant AFAIK.
  + Ralf.. is the default multlib the same as 603?

No, the default is identical to the -m750.


I guess I am seeing that some of the variants could be overkill. The same core is used in lots of CPUs. Can we analyze each multilib and justify its existence?

The problem is the powerpc port in RTEMS, not newlib nor GCC. Many of
these multilib variants share the same ISA/ABI etc. but they do not
share the same code in RTEMS (cf. cpukit/score/cpu/powerpc/rtems/score/cpu.h)



I'd propose to discuss doing away with some of the 604 compatible variants
- probably, just one of them would be enough, e.g.:

a) 604 with no altivec
b) 7400 with altivec

Let me ask differently: Which altvec variants do you want to add?

In RTEMS/CVS, we already have a 7400 BSP. With GCC-4.0, -m7400 already
implies altivec. AFAIS, this BSP probably doesn't work when having been
built against a multilib'ed RTEMS. => I see a demand (need?) for a -m7400/altivec multilib variant, but I
don't know if it is required or if this would be useful.


I don't know if altivec is useful for other powerpc-cpu-variants.

I think we can kill more than enough to make it possible to add.

GCC thinks a lot of -mXXX are -mppc internally anyway and RTEMS PROBABLY
doesn't care until you get to libcpu and libbsp.

Unfortunately nothing could be further from the truth than this, as far as the powerpc is concerned - It is the design issue/flaw I have been repeatedly referring to.

cpukit/score/cpu/powerpc/rtems/score/cpu.h is ca. 700 lines in size,
scattered with ca 30 different defines, which all are candidates for
conditionally compiling something somewhere. The problem there is to
identify which are actually important and which are not.

Try to track how *ALIGNMENT defines are set up and you'll probably
experience what I am referring to.

Turns out the more you live, the more you learn. :)

PPC_CACHE_ALIGNMENT appears to be the same for almost all configurations. It can be condensed to 1 define of 16 as best I can tell. It is only used to properly align the bitmap structure used
for thread scheduling. If a multlib can distinguish the core in the 7455 and 8260, they use 32. The 74xx has an Altivec so that would be a good candidate to multilib on and use 32.


PPC_ALIGNMENT is basically what the heap has to align to. Does a double
have to be 8 or 4-byte aligned? A quick guess is that if you have hardware FPU, then make it 8, else make it 4.


I picked on PPC_I_CACHE and PPC_D_CACHE. The only place they are used
is in libcpu/powerpc/.../cache.h. So they can be moved to that file I think.


Also as far as I know, there was NEVER an RTEMS user on the 601 or 602.
Those still say "Submitted with original port -- book checked only." so that makes them high priority kill targets if they present any issues.
But all I see are alignment constants for them which are easy to get out of the score.


Can we deduce PPC_HAS_FPU directly from a cpp predefine?

PPC_HAS_DOUBLE follows directly from PPC_HAS_FPU so I don't see any hint
of a CPU really having only 32-bit floating point registers. Doing a quick search of gcc, I don't see such an animal either. Looks like a
target to kill.


PPC_USE_MULTIPLE only appears in the bsp. I don't know on this but it could move to libcpu.

Ralf.. do you want to take a stab at moving those and let's see what is next?

--joel