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


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


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