This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: PPC AltiVec request: add an abi variant


On Mon, 3 Mar 2003, Matt Thomas wrote:

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

Here's what I found.

http://e-www.motorola.com/brdata/PDFDB/docs/ALTIVECPIM.pdf

"3.2 Register Usage Conventions

The register usage conventions for the vector register file are defined as
follows:

v0-v1		General use		Volatile (Caller save)
v2-v13		Parameters, general	Volatile (Caller save)
v14-v19		General			Volatile (Caller save)
v20-v31		General			Non-volatile (Callee save)"

This appears to be the current official PowerPC EABI industry working
group specification. It's stated the standard is still under review and
subject to change. The appropriate place to request this may be with the
working group.

> >You're either mistaken, or not expressing the concept clearly?
> 
> Or I gave the audience more credit that I should have.

You were too vague, and I couldn't deduce whether you were referencing
system calls or a interrupt-driven context switch.

Toshi



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