This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc
- From: Tom Gall <tom_gall at vnet dot ibm dot com>
- To: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- Cc: Brian Grayson <Brian dot Grayson at freescale dot com>, Paul Mackerras <paulus at samba dot org>, libc-alpha at sources dot redhat dot com, sjmunroe at us dot ibm dot com
- Date: Thu, 22 Dec 2005 20:13:13 -0600 (CST)
- Subject: Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc
- References: <20051221222624.GK2258@nylon.am.freescale.net> <1135302280.10035.236.camel@gaston>
Food for thought .. but if there are good reasons for having perfect
detail as to the processor one is on, why not just send on the PVR and be done
with it.
On Fri, 23 Dec 2005, Benjamin Herrenschmidt wrote:
> > 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.
>
> I think it was a mistake to add the microarch like POWER4 in there. It
> should have been a separate entity, possibly the ELF_PLATFORM string.
> The change was done in a rush but not properly thought out (and that's
> partially my fault too).
>
Perhaps we ought to compile the performance impacts one might want to
consider so we can continue discussions on what all might (and might not)
be reason to make sure that whatever design we end up with is going to
fit.
<big snip>
> > > 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.
>
> In addition, it might be worth using the vdso for some very processor
> specific things, thus getting the benefit automatically without
> requiring a different libc. I've been pondering putting implementations
> of memcpy and spinlocks in there... food for thoughts at this point
> though.
Personally I think this is good food for thought.... sorta dark chocolate
in the cubboard ... yearning to be eaten ... :-)
Regards.
Tom