ppc multlibs and BSP removal was Re: powerpc altivec support

[Ralf Corsepius]

On Wed, 2005-02-09 at 19:40 -0800, Till Straumann wrote:
> Ralf Corsepius wrote:
> > 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. :)
> 
> Absolutely - and life is still too short...
Whom are you telling? :)

> >>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.
> 
> Some PPCs have 16byte caches [860] most 32 byte.
> In any way - before considering a multilib
> 
>    a) check the implications of always using 32byte alignment by default
>       [user with special demands such as squeeze ram might need to rebuild
>       a new configuration].
>    b) if that's not practical, consider a run-time check. Cache line size
>       can easily be determined at startup and read from a variable.
> 
> >>
> >>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.
> 
> Might be an ABI issue anyways. AFAIK, malloc() must return memory
> aligned properly for any data type (except vectors, altivec has
> a special allocator).
> 
> SYSV demands that long double variables shall be 16-byte aligned,
> EABI relaxes this to 8-byte alignment.
> 
> 
> > 
> > Can anybody confirm these assumptions? If they hold, this was a
> > breakthrough, causing powerpc.h to substantially collapse.
> 
> So far, we really only have SYSV vs EABI
OK - But, what do we have: SYSV or EABI?

We have PPC_ABI_EABI set in RTEMS, we have -nno-eabi in GCC and seem to
be using sysv rules in GCC.

=> We are back to PR195

> >>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.
> 
> I agree.

Meanwhile I am not sure anymore.

What is the purpose of PPC_HAS_FPU and PPC_HAS_DOUBLE?

Do they describe that a CPU *has* FPU rsp. DOUBLE support, or do they
describe that RTEMS *uses* the FPU rsp. DOUBLE.

In the latter case, tying PPC_HAS_FPU to _SOFT_FLOAT would be correct,
in the former case this would not necessarily be correct.

E.g. a CPU with FPU built in might need a different task switch/require
different instructions inside a task-switch than a CPU w/o FPU, even if
not actually using the FPU. I have never seen a such a case, so I assume
PPC_HAS_FPU is meant to mean "uses FPU".


> >>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.
> > 
> 
> Dunno.
Partial correction:
I don't see such an animal in GCC, but I see one in RTEMS.

The m602 seems to be wanting to use
#define PPC_HAS_FPU 1
#define PPC_HAS_DOUBLE 0

PPC_HAS_DOUBLE is primarily used in task-switches, so I am wondering
what PPC_HAS_DOUBLE actually means:
* The CPU lack some (double) instructions, therefore requires a
customized task-switch. Makes me wonder, what happens with GCC generated
FPU code on these CPUs.
* The CPU needs customization because it lacks a feature.

Ralf