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: Steve Munroe <sjmunroe at us dot ibm dot com>
- To: Brian Grayson <Brian dot Grayson at freescale dot com>
- Cc: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, libc-alpha at sources dot redhat dot com, Paul Mackerras <paulus at samba dot org>, Tom Gall <tom_gall at vnet dot ibm dot com>
- Date: Fri, 6 Jan 2006 13:57:42 -0600
- Subject: Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc
Brian Grayson <Brian.Grayson@freescale.com> wrote on 01/06/2006 09:38:53
AM:
> On Thu, Jan 05, 2006 at 01:33:33PM -0600, Steve Munroe wrote:
> > Brian Grayson <Brian.Grayson@freescale.com> wrote on 12/28/2005
03:34:17 PM:
> ...
> > > A few years ago, the e500 ABI specified mechanisms for both
> > > toolchains and code to obtain information about what APUs are
> > > expected:
> ...
> > Note that glibc does not support the BOOKe ABI.
>
> There seems to be some confusion about Book E. I want to
> point out a few things here so that the confusion is not
> perpetuated.
>
> There is no Book E ABI, as Book E is userland-compatible with
> classic Book 1. Nearly all of Book E's changes pertain to
> supervisor mode (Book 3): different MMU style that supports
> easier programming and variable size pages, recoverable
> machine-check, higher-priority critical interrupts,
> programmable exception vector locations, etc. Many of these
> features are also in the Book E-compliant IBM 440 parts, which
> AFAIK did not require a new ABI.
>
I guess I was confused by the 78,800 hits google returns for "eABI"
> It just so happens that the first Book E implementation from
> Freescale, the e500 core, also added a DSP-like Signal
> Processing Engine (SPE), which overlays on top of the GPRs.
> _That_ required a new ABI, the e500 ABI, to handle the changes
> w.r.t. passing this new datatype __ev64_opaque__. The changes
> are very similar to what was done for AltiVec in the 90s,
> except that Freescale decided to also pull in some of the EABI
> changes, so that there wouldn't need to be an e500 ABI _and_ an
> e500 EABI. So, sdata0 is supported, a few new relocations are
> supported, and software floating-point emulation is documented.
>
Ok, so the e500 core is supported in the subset powerpc32/nofpu form.
SPE requires a separate ABI and a separate port.
AltiVec/VMX it was separate facility with independent register set. So it
could be added as a versioned extention to the existing ABI. And that was
no walk in the park.
The SPE overlaying the gprs with fprs changes the ABI and breaks so many
internal dependences it has to be a separate ABI and port. This means that
it has to have a different configure target and SPE unique code has to go
into a different part of the tree.
> But note that, just like the EABI and the AltiVec Supplement,
> the e500 ABI is compatible with the classic ABI where possible.
> For ordinary integer code it is highly likely that it can be
> linked dynamically or statically with classic ABI libraries,
> and everything will just work. Same goes for AltiVec -- most
> applications that take advantage of AltiVec and its ABI, with
> its different stack alignment, larger jmp_buf, additional
> printf/scanf support, etc. will Just Work when linked with
> non-AltiVec-aware code.
>
What are you proposing here? Running e500 in the powerpc32/nofpu ABI
subset, OK. Support for SPE is another matter.
> So, to summarize, Book E != SPE. glibc already supports Book
> E, because it supports classic.
>
My concern is that supporting "classic" is holding back powerpc
performance in general. I started this proposal (and what became
--with-cpu) to enable the full potential of PowerPC Version 2.0+
Architecture where it exists, while continuing support for the "classic"
powerpc.
So my goal is to enable a separation of concerns between the (sometimes)
competing interests of the "enterprise", "desktop", and "embedded" worlds.
I think the AT_PLATFORM+dl_procinfo proposal (and --with-cpu=) does that.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center