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 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]