[RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc, revised

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc, revised

Steve Munroe
This RFC has been through the wash and spin cycles a couple of times with
the wider community and I think is in final form. If ther are no
objections I will submit a small patch for libc/powerpc to match the
proposal below.

-------------------

The recently committed dl-procinfo support for powerpc provides names for
AT_HWCAP bits as of 2.6.15. This update also defines HWCAP_IMPORTANT
support that allows for HWCAP based extensions to the library search path.
The intent is to allow the loader (ld.so) to select the most appropriate
version of a library given the hardware we are running on. This is
equivalent the support for i686 optimized libraries for the i386 platform.

The 2.6.15 kernel defines the following AT_HWCAP bits:

#define PPC_FEATURE_32             0x80000000 /* 32-bit mode. */
#define PPC_FEATURE_64             0x40000000 /* 64-bit mode. */
#define PPC_FEATURE_601_INSTR      0x20000000 /* 601 chip, Old POWER ISA.
*/
#define PPC_FEATURE_HAS_ALTIVEC    0x10000000 /* SIMD/Vector Unit.  */
#define PPC_FEATURE_HAS_FPU        0x08000000 /* Floating Point Unit.  */
#define PPC_FEATURE_HAS_MMU        0x04000000 /* Memory Management Unit.
*/
#define PPC_FEATURE_HAS_4xxMAC     0x02000000 /* 4xx Multiply Accumulator.
 */
#define PPC_FEATURE_UNIFIED_CACHE  0x01000000 /* Unified I/D cache.  */
#define PPC_FEATURE_HAS_SPE        0x00800000 /* Signal Processing
Extentions.  */
#define PPC_FEATURE_HAS_EFP_SINGLE 0x00400000 /* SPE Float.  */
#define PPC_FEATURE_HAS_EFP_DOUBLE 0x00200000 /* SPE Double.  */
#define PPC_FEATURE_NO_TB               0x00100000 /* 601/403gx have no
timebase.  */
#define PPC_FEATURE_POWER4              0x00080000 /* POWER4 ISA 2.00
level.  */
#define PPC_FEATURE_POWER5              0x00040000 /* POWER5 ISA 2.01
level.  */
#define PPC_FEATURE_POWER5_PLUS 0x00020000 /* POWER5+ ISA 2.02 level.  */
#define PPC_FEATURE_CELL_BE             0x00010000 /* CELL Broadband
Engine.  */

To which we will add the following:
#define PPC_FEATURE_BOOKE          0x00008000 /* BOOKE ISA features.  */

These bits where given the following procinfo names
        "ppc32",
        "ppc64",
        "ppc601",
        "altivec",
        "fpu",
        "mmu",
        "4xxmac",
        "ucache",
        "spe",
        "efpsingle",
        "efpdouble",
        "notb",
        "power4",
        "power5",
        "power5+",
        "cell"

To which we will change/add the following: "cell" will become "cellbe",
add "booke".

The initial proposal was sufficient for current needs of PowerPC 64-bit,
but concern was expressed that PowerPC 32-bit and embedded where not
covered. Also the concern was raised that HWCAP was a finite resource that
might be exhausted by the large variety of 32-bit PowerPC (cpu_type)
variants and future 64-bit processors.

It was suggested that AT_PLATFORM is a better mechanism for supporting a
large variety of cpu-types for compiler (micro-architecture)
optimizations. And AT_HWCAP should be focused on ISA features and optional
execution units.

The PPC_FEATURE_POWER4, PPC_FEATURE_POWER5, PPC_FEATURE_POWER5_PLUS are
still useful because they represent ISA Version levels where each level
introduces new user state instructions:

   PPC_FEATURE_POWER4      -> PowerPC ISA Version 2.00
   PPC_FEATURE_POWER5      -> PowerPC ISA Version 2.01
   PPC_FEATURE_POWER5_PLUS -> PowerPC ISA Version 2.02

Perhaps these should be renamed or aliased, to something like
PPC_FEATURE_ISA_POWER4, but this is not critical to this (dl-procinfo)
proposal. For library search these are redundant with the AT_PLATFORM
information, so they will be removed from the HWCAP_IMPORTANT mask.

But for the embedded space there we need a HWCAP bit to identify the user
mode "isel", "mbar", "msync", etc ISA feature associated with BOOKE. So we
propose adding HWCAP bit for PPC_FEATURE_BOOKE to represent this ISA
extention common in the embedded space.

The new HWCAP_IMPORTANT mask is:

+#define HWCAP_IMPORTANT        (PPC_FEATURE_HAS_ALTIVEC   \
+                       | PPC_FEATURE_CELL_BE       \
+                       | PPC_FEATURE_BOOKE)

With this change AT_PLATFORM provides the cpu_type selection while
AT_HWCAP provides ISA modifiers for the ALTIVEC, CELL_BE, and BOOKE
features. ALTIVEC, CELL_BE, BOOKE are exclusive features so a maximum 2
directory levels are introduced.

The specific strings provided in AT_PLATFORM are "inspired" by the gcc
-mcpu= cpu_type names.  Self defining names are used as is (power4,
power5, ...). For AT_PLATFORM numeric chip_type names (970, 7450, ...) are
prefixed with "ppc" (ppc970, ppc7450). Where the cpu_type has aliases (G5
is an alias for 970) the more generic name is used (i.e. ppc970 not G5 and
ppc7450 not G4).

For 64-bit processors and kernels we can assume (at least) the following
AT_PLATFORM names:  "rs64", "power3", "power4", "power5", "power5+",
"ppc970" (AKA G5), and "ppc-cell-be".

For 32-bit processors and kernels we propose a longer list as dictated by
the cpu_types the kernel supports. The current list is: "ppc403",
"ppc405", "ppc440", "ppc440GP", "ppc601", "ppc603", "ppc604", "ppc7400",
"ppc7450" (AKA G4), "ppc750" (AKA G3), "ppc823", "ppc8540".

Note: the "powerpc" value is reserved and only used for the case where the
PVR value is unrecognized.

The dl-procinfo implementation uses this information to augment the
library search list. The proposed correspondence between processors and
runtime library search directories (assuming the current nptl paths) are:

processor     library search
==========    ============
power4        /lib[64]/tls/power4, /lib[64]/tls, /lib[64]
power5        /lib[64]/tls/power5, /lib[64]/tls, /lib[64]
power5+       /lib[64]/tls/power5+, /lib[64]/tls, /lib[64]
970/G5        /lib[64]/tls/ppc970/altivec, /lib[64]/tls/ppc970,
/lib[64]/tls/altivec,
              /lib[64]/tls, /lib[64]

7450/G4       /lib/tls/ppc7450/altivec, /lib/tls/ppc7450,
/lib/tls/altivec, /lib/tls, /lib
750/G3        /lib/tls/ppc750, /lib/tls, /lib
440           /lib/tls/ppc440/booke, /lib/tls/ppc440, /lib/tls/booke,
              /lib/tls, /lib

Note: The additional "altivec" level for the 970/7450 is an artifact of
the PPC_FEATURE_HAS_ALTIVEC modifier from AT_HWCAP. The "altivec"
directory can be used to store Altivec optimized libraries that are common
across platforms. The simularly for the "booke" level for the 440 is an
artifact of PPC_FEATURE_BOOKE.


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

Reply | Threaded
Open this post in threaded view
|

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

Ulrich Drepper
Steve Munroe wrote:
> +#define HWCAP_IMPORTANT        (PPC_FEATURE_HAS_ALTIVEC   \
> +                       | PPC_FEATURE_CELL_BE       \
> +                       | PPC_FEATURE_BOOKE)

Remove the booke stuff.  There is no reason to punish people for
something only embedded people are interested in.  Those freeloaders in
any case recompile so they can add it to their code.

--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖


signature.asc (259 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Herrenschmidt
On Fri, 2006-01-13 at 14:21 -0800, Ulrich Drepper wrote:
> Steve Munroe wrote:
> > +#define HWCAP_IMPORTANT        (PPC_FEATURE_HAS_ALTIVEC   \
> > +                       | PPC_FEATURE_CELL_BE       \
> > +                       | PPC_FEATURE_BOOKE)
>
> Remove the booke stuff.  There is no reason to punish people for
> something only embedded people are interested in.  Those freeloaders in
> any case recompile so they can add it to their code.

Not all users of booke CPUs users are freeloaders ;-) I don't like just
removing it from the mask for the sake of it...

Ben.


Reply | Threaded
Open this post in threaded view
|

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

Tom Gall
In reply to this post by Ulrich Drepper


On Fri, 13 Jan 2006, Ulrich Drepper wrote:

> Steve Munroe wrote:
> > +#define HWCAP_IMPORTANT        (PPC_FEATURE_HAS_ALTIVEC   \
> > +                       | PPC_FEATURE_CELL_BE       \
> > +                       | PPC_FEATURE_BOOKE)
>
> Remove the booke stuff.  There is no reason to punish people for
> something only embedded people are interested in.  Those freeloaders in
> any case recompile so they can add it to their code.

I don't see the reason for it's removal. While you may have an axe to
grind against embedded developers, I don't think that has a place here.

Regards,

Tom
Reply | Threaded
Open this post in threaded view
|

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

Brian Grayson-2
In reply to this post by Steve Munroe
  This proposal looks like it meets Freescale's immediate and
longer-term needs.  Thanks, Steve (and the others who have
contributed on and off the list), for all your work.

  Brian Grayson
--
Brian Grayson, SysPerf (System Performance, Modeling, and Simulation)
[hidden email]
Somerset Design Center
Freescale Semiconductor
Austin, TX
Reply | Threaded
Open this post in threaded view
|

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

Paul Mackerras
In reply to this post by Steve Munroe
Steve Munroe writes:

> It was suggested that AT_PLATFORM is a better mechanism for supporting a
> large variety of cpu-types for compiler (micro-architecture)
> optimizations. And AT_HWCAP should be focused on ISA features and optional
> execution units.

The kernel changes to make an AT_PLATFORM aux table entry are now
upstream and will be in 2.6.16.  The set of strings is as listed in
your proposal with the addition of "ppc440gp", "ppc5554", and
"ppc8548".

Paul.