ppc multlibs and BSP removal was Re: powerpc altivec support

Thu Feb 10 12:32:56 UTC 2005

Ralf Corsepius wrote:
> 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

I think we are using EABI not System V.

>>>>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_FPU means has and RTEMS may use.  You still have the task 
attributes if the application doesn't want to use the FPU and RTEMS will 
disable the FPU on a per task basis

PPC_HAS_DOUBLE is a bit harsher.  If a CPU implementation had only 
32-bit FP registers (rather than 64-bit ones), then we could only save 
them that way.

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

The 602 manual definitely confirms it has a 32-bit FPU.  I haven't found 
yet what it does for doubles except the "emulation" keyword in the 
description.  I would leave the code in and let's not worry about it as 
a multilib variant.  Trip it ONLY if explicitly built with 602 defined 
after doing the multilib checks.  I believe gcc does care about this
feature and will generate 64-bit lds/stores.

As a practical matter, no one that I know if is using this CPU.  Don't 
completely kill it, just don't waste CPU cycles building a multilib 
specifically for it.

--joel