ppc multlibs and BSP removal was Re: powerpc altivec support

[Ralf Corsepius]

On Thu, 2005-02-10 at 06:32 -0600, Joel Sherrill  wrote:
> Ralf Corsepius wrote:
> > On Wed, 2005-02-09 at 19:40 -0800, Till Straumann wrote:

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

Well, as I understand it from digging in GCC's and RTEMS sources,
powerpc-rtems-gcc defaults to "sysv-eabi" (whatever this is).

All I can say is:

* we are using -mcall-sysv. 
AFAIU, this means we are using SYSV calling conventions.

* The default stack boundary (This is the term GCC uses) is 8.

* -mno-eabi switches the stack boundary to 16.

* Explicitly passing -meabi doesn't seem to have any effect on the stack
boundary. Therefore, I conclude the implicit default is -meabi.

* ATM, the multilibs are being built *explicitly* using -mno-eabi,
i.e. newlib and GCC's libs are being built with a stack boundary of 16.
According to a comment in rs6000.c, this implies they are EABI and SYSV
compatible.

* There doesn't seem to be a preprocessor define denoting if using EABI
or SYSV.

So - what are we using? I don't know.

AFAIU, we are using SYSV for newlib/GCC (-mno-eabi -mcall-sysv) and a
corrupted multilib'ed cpukit (-mno-eabi -mcall-sysv -DPPC_ABI_EABI).


> > 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.
OK, that's doable.

Ralf