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

[Brian Grayson <Brian dot Grayson at freescale dot com>]

On Tue, Dec 27, 2005 at 11:39:40PM -0700, Benjamin Herrenschmidt wrote:
> On Wed, 2005-12-28 at 00:11 -0600, Steve Munroe wrote:
> > 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.

  Two quick points, and some info about APUinfo for those that
don't know about it:

  - FSL usually adds any new instructions as an optional APU,
    which tends to be self-contained (AltiVec, SPE, VLE) or
    mostly for privileged use (perfmon, machine check,
    cache-locking, branch-locking).  isel is one notable
    exception to this.

  - FSL has usually avoided adding or removing from the _base_
    instruction set, for fear of fragmenting the ISA and thus
    causing our customers no end of grief ("my e9999 no-AltiVec
    no-isel binary won't run on my old 603.  What gives?") -- I
    think FSL sells more legacy processors (like 603e-derived
    SOCs) than IBM does, so our customers' and our concerns are
    flavored by that.

  A few years ago, the e500 ABI specified mechanisms for both
toolchains and code to obtain information about what APUs are
expected:

  - the .PPC.EMB.apuinfo section in an object file or
    executable specifies what version of which APUs is required
    by the object.

  - the __get_apu_revision() function provides a mechanism for
    userland to identify what APUs are available on the current
    silicon, and/or emulatable by the current OS.

  Note that this was not meant to be an e500-only feature, but
rather something that could be used on many cores going forward.

  I believe apuinfo section support is in most embedded PPC
toolchains nowadays (it's in binutils, for example), but I am
not sure if all OSs support __get_apu_revision() yet.  We did
not specify an AUX_VECTOR type to specify APUinfo, but one
could be added.

  It sounds like AT_HWCAP and apuinfo are two different
solutions to the same problem, with different strengths etc.
The APUinfo section provides finer-grain control (which
revision of which APU, with support for up to 2^16 APUs each
with up to 2^16 revisions), whereas HWCAP, with its limited
bits, can only support the coarse yes/no control.

  Brian