ppc multlibs and BSP removal was Re: powerpc altivec support

[Joel Sherrill <joel@OARcorp.com>]

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