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: Brian Grayson <Brian dot Grayson at freescale dot com>
- To: Steve Munroe <sjmunroe at us dot ibm 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 09:38:53 -0600
- Subject: Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc
- References: <20051228213417.GA2258@nylon.am.freescale.net> <OFD75860C0.0939F3A6-ON862570ED.00692261-862570ED.006B7224@us.ibm.com>
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.
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.
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.
So, to summarize, Book E != SPE. glibc already supports Book
E, because it supports classic.
Brian
--
Brian Grayson, SysPerf (System Performance, Modeling, and Simulation)
Brian.Grayson@freescale.com
Somerset Design Center
Freescale Semiconductor
Austin, TX