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


Brian Grayson <Brian.Grayson@freescale.com> wrote on 12/21/2005 04:26:25
PM:

> Steve Munroe wrote:
> > Christoph Hellwig <hch@lst.de> wrote on 12/15/2005 06:36:01 AM:
> >
> > > > We have made a deliberate decision not to identify older processor
> > > > generations (POWER3, G4). They are no longer in production and/or
are
> > > > adequately covered by the current glibc implementation. They
> will continue
> > > > to be supported by current base/default implementation (as
> defined by gcc
> > > > options -mcpu=powerpc for 32-bit and -mcpu=powerpc64 for 64-bit).
> > >
> > > That's not true.  G4, G3 and even G2-based microarchitectures are
still
> > > in production at motorola.  Not to mention things like the 8xx.
> >
> > Did you miss the "or are adequately covered by the current glibc
> > implementation" part?
> >
> > Note: I did not say they are not supported, I did say that I
(personally)
> > was not going to do anything extra for them. I have my hands full
keeping
> > on top of the current IBM products (along with all my other jobs).
> >
> > But you should be supporting my efforts on this and the related
--with-cpu
> > support. I have done all the heavy lifting to enable the general
> > mechanism. If you are supportive of this effort, then please say so.
>
>   First of all, yes, we appreciate what you've done!
>
> > If you are vitally interested in supporting G2, G3, G4 then you will
need
> > to:
>
>   Freescale (formerly Motorola SPS) is interested in supporting
> all of these and more.  The e200, e300 (G2), e500, and e600
> (G4) cores are all supported by gcc's -mcpu= options
> (e.g., -mcpu=8540), so I think the main thing is to make sure
> that the proper bits are allocated now.  e200 has a feature
> that would require another HWCAP bit (compressed code, aka
> "VLE"), for example.
>
Wo, Lets not throw in the kitchen sink with this. First gcc -mcpu support
is necessary but not sufficient for mainline glibc support. Also we need to
distinguish between building glibc (which only involves --with-cpu) and
selecting from multiple versions of libc.so at runtime (which does require
AT_HWCAP bits).

You don't need HWCAP_IMPORTANT support to build an SDK for an embedded
processor. You can use --with-cpu= to select any chip optimization you have
written and implicitly assert -mcpu= for the build. Plus it is a separate
negotiation with the glibc maintainers for what code is included in
mainline, ports, or elsewhere.

HWCAP_IMPORTANT support and AT_HWCAP bits are required to allow distros to
ship fat rpms which include more then one copy of libc.so (libm, librt,
libpthread...) and select the best match to the processor chip at run time.
So this feature is specific to building a single binary distribution for
general use (i.e not embedded).

So adding popular desktop and laptop cpu_types (G4, G3) is reasonable,
because this may be of general interest to distro's. But naming every chip
in the inventory is not. There is a limit to the number of variants that
anyone is willing to build ... and that is also a separate negotiation.

Note: I did not ask for AT_HWCAP bits for power, power2, power3 etc. I am
focused on current and future production starting with PowerPC Architecture
Version 2.0 (power4).

Finally. BOOKe processors on not covered by this. I understand that the
common intersection of BOOKe and PowerPC (powerpc32-nofpu) is usable in
restricted circumstances, but the full BOOKe (e500) ISA is not compatible
with the PowerPC ISA. So BOOKe requires a separate ABI and a separate libc
port. That is beyond the scope of this proposal.

>   By the way, putting on my architecture hat, I noticed that
> the current allocation is all in-order from MSB down, going
> from computation mode (32/64) to ISA features (601 down to
> EFP-double) to system features (unified cache and no timebase),
> to chip microarch, with no breaks for future additions.  Would
> it be feasible to provide a break between NO_TB and POWER4
> (perhaps number the uarchs from LSB up?), so that if a new ISA
> extension is done, the bit encoding makes sense?  Something
> like "isel" seems worthy of addition, since that is
> UISA-visible and can have substantial performance impact.
>
Its might be too late for that as the changes is already upstream in 2.6.15

>   Also, is the 32-bit mode "true" 32-bit mode, and not the 970
> 32-bit mode?  That is, is a binary marked with PPC_FEATURE_32
> _guaranteed_ to run on a 601 without any program exceptions?  We
> have heard rumors that AIX and Apple, even in 32-bit mode, take
> advantage of the fact that 64-bit instructions can still be
> executed on a 970 in 32-bit mode.
>
No. PPC_FEATURE_32 is set for any chip that supports at least -mcpu=common.
This includes 601 and all 64-bit implementations. 601 is a special case
because it is not compliant with the full PowerPC Architecture Version 1.0
spec (it has deviations, like not supporting the timebase). So the kernel
sets both PPC_FEATURE_32 and PPC_FEATURE_601_INST for this case. The kernel
sets both PPC_FEATURE_32 and PPC_FEATURE_64 for 64-bit implementations.

> > 1) Negotiate with Paul Mackerras to get bits allocated in AT_HWCAP from

> > the kernel.
>
>   We will work on doing this.
>
> > 2) Verify that gcc has the -mcpu= support you need. If not you need to
> > negotiate with David Edelsohn to get any -mcpu= support and __ARCH_
> > macro's you might need.
>
>   Done, or in progress, for all of our production parts (e200,
> e300, e500, e600).
>
See comment above about BOOKe ...

> > 3) Provide detail analysis and justification of why the (widely used)
> > processor/chip that you want to support is not well served by the
current
> > (default) implementation.
>
>   We have seen some significant speedups on certain benchmarks
> (including SPEC) using some of the optimized libraries
> internally.  If deeper justification is required, we can work on that.
>
> > 4) Provide optimized implementations of high use functions where
needed.
>
>   Some of this has already been done (libcfsl_e500,
> libmotovec), and more will be done in the future.
>
This proposal is about providing optimized implementations of the existing
libc API and library set.  This implies signing the copyrights over to FSF
and porting appropriate code into the glibc (and power-cpu add-on)
framework.

However. Arbitrary and chip specific expansion of the API will likely be
rejected by the maintainers. Any expansion of the API will be require
separate negotiation with the maintainers and community.

> > Then we can work together to update dl-procinfo to support what you
come
> > up with.
>
>   Thanks for working on this.
>

You are welcome!

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]