[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ppc multlibs and BSP removal was Re: powerpc altivec support
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  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
* There doesn't seem to be a preprocessor define denoting if using EABI
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.