ppc multlibs and BSP removal was Re: powerpc altivec support

[Ralf Corsepius]

On Wed, 2005-02-09 at 16:25 -0600, Joel Sherrill  wrote:
> Ralf Corsepius wrote:

> >>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.
Can anybody confirm these assumptions? If they hold, this was a
breakthrough, causing powerpc.h to substantially collapse.

> 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?
Conversely, I think we must.

Adding a _SOFT_FLOAT != PPC_HAS_FPU preprocessor check reveals
PPC_HAS_FPU to be inconsistent in comparison to _SOFT_FLOAT, i.e.
broken.

> 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.
Neither do I.

> 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?
I am already working on this - The limiting factor is the "sheer amount"
of multilibs and BSPs. One iteration takes 24hours+ ;).

Ralf