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

[Benjamin Herrenschmidt <benh at kernel dot crashing dot org>]

On Wed, 2005-12-28 at 00:11 -0600, Steve Munroe wrote:

> "power4" maps to PowerPC ISA Version 2.00
> "power5" maps to PowerPC ISA Version 2.01
> "power5+" maps to PowerPC ISA Version 2.02
> 
> These AT_HWCAP bits ARE valid features (each level adds new instructions to
> the ISA, as well as microarch discriminators). I think "cell" has other
> unique ISA features that justifies its inclusion in the AT_HWCAP.

Yup, though there are additional implementation specific feature bits
that gets added to that, but yes.

> I don't have this kind info for the various flavours of PPC32 processor. I
> happily defer to those who have this knowledge to decide.

We should discuss that with the freescale folks.

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

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

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.

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 ?)
 
> I offer the following proposal for powerpc64: Add AT_PLATFORM support where
> the <platform> strings match the <cpu_type> strings supported by gcc. This
> harmonises library search path names with --with-cpu= targets.
> 
> One detail to work out relates to G5. Is the AT_PLATFORM for a G5, "G5" or
> "970". Both are valid -mcpu= strings but I should ask David Edelsohn if
> there is any different in the code gen. It would be simpler to use "970"
> for both G5 and JS20.

Agreed.

> This nets out to: "power2", "power3", "power4", "power5", "power5+", and
> "970" (and "cell"?).
> 
> The AT_PLATFORM details for power32 kernel are more complicated and can be
> resolved independently.