This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PPC AltiVec request: add an abi variant
- From: Matt Thomas <matt at 3am-software dot com>
- To: <tm_gccmail at mail dot kloo dot net>
- Cc: gcc at sources dot redhat dot com
- Date: Mon, 03 Mar 2003 13:00:32 -0800
- Subject: Re: PPC AltiVec request: add an abi variant
- References: <5.1.1.6.2.20030303102035.0526c8b0@3am-software.com>
At 01:38 PM 3/3/2003, tm_gccmail at mail dot kloo dot net wrote:
On Mon, 3 Mar 2003, Matt Thomas wrote:
> To facilitate using AltiVec in the NetBSD kernel, I'd really like
> a environment where all AltiVec registers were considered to be
> callee-saved. If that happened, the kernel wouldn't have to incur
> the overhead of saving/restoring AltiVec state in the kernel other
> than where it's used.
Why would the Altivec registers require saving/restoring where they're
not used?
Because the kernel is a separate "user" of AltiVec from a normal
user process, unless the AltiVec state is preserved, any use of
AltiVec will obliterate any previous user's state. On entering
the kernel, the kernel saves all the integer registers (along with
LR, CTR, CR, etc.) so it can use them. It then restores them when
it returns to the user. It could do the same thing for AltiVec but
that's a significant amount of overhead. But the kernel does not
whether it will be using AltiVec so avoiding that overhead would be
good. Now if each routine that uses any AltiVec register could make
sure that upon return that the register contents were identical to
entry, then the need to always save and restore would do away.
You're either mistaken, or not expressing the concept clearly?
Or I gave the audience more credit that I should have.
--
Matt Thomas Internet: matt at 3am-software dot com
3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/
Cupertino, CA Disclaimer: I avow all knowledge of this message