This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc



Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 12/28/2005
12:39:40 AM:

> On Wed, 2005-12-28 at 00:11 -0600, Steve Munroe wrote:
>
> > If the kernel also supported AT_PLATFORM and returned "970",
dl-procinfo
> > would combine this with the AT_HWCAP & HWCAP_IMPORTANT bits and add the
> > follow search paths:
>
> Which raises the question of wether we should return "970" or "power4"
> in AT_PLATFORM... I understand your problem. In fact, we are really
> dealing with 4 type of informations here :
>
It depends on planned usage of AT_PLATFORM. If the primary usage is for
dl-procinfo library search path selection, then power4 is a better choice.
For scalar code (libc, libm, ...) the instruction set and scheduling are
the same. Vector code can still use the altivec directory via AT_HWCAP and
PPC_FEATURE_ALTIVEC.

Alternatively there would be separate "power4" and "970" directories and
970 libraries would be duplicates or symlinked back to the power4
libraries.

> 1 - The microarchitecture (or family). In this regard, P4 and P5 are the
> same as they basically have the same instruction scheduling
> requirements, no ? While Cell is different ...
>
Power5 has a deeper storage queue then power4 which impacts scheduling.
Also power5 adds the popcntb instruction (ISA version 2.01).

> 2 - The actual processor model (P4,P4+,970,P5,P5?+,...)
>
> 3 - The specific processor revision (The actual PVR).
>
> 4 - Additional feature bits that define user-interesting features that
> can exist accross microarchitectures, like Altivec
>
> 1 is pretty much what we just added to HWCAP, though it can still be
> debated wether it should be one bit per microarch, or if we should
> reserve, let's say 8 bits, and have a value stuffed there. That would
> give us more flexibility in the future... 4 was already there, it's the
> old-style HWCAP usage.
>
Perhaps we stumbled into this by accident and the bits are miss named, but
PPC_FEATURE_[POWER4|POWER5|POWER%_PLUS] do represent additional ISA
features.

I am not sure we want to mix scalar and bits values in AT_HWCAP.

> 2 and 3 are basically the 2 half of the PVR (2 is the top bits, 3 is the
> entire PVR).
>
> >From what I've seen so far, the -mcpu in gcc tends to try to "know"
> about every single CPU revision out there, which is way beyound our
> realistic needs I suppose...
>
> (BTW. Do we really need to differenciate P5 and P5+ at that level ? Do
> they have any user-space significant difference ?)
>
The PowerPC ISA Version 2.02 (P5+) adds 5 new user state instructions.
These should provide measurable improvement in SPECfp.

Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]