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
At 06:52 AM 3/4/2003, Peter Bergner wrote:
Matt Thomas wrote:
> 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.
I don't know the NetBSD kernel, but can't you play the same game
Linux/PPC does for AltiVec and the FP registers which uses lazy
save/restore (actually only lazy save on non-SMP kernels) of the
register contents using the FP unavailable and AltiVec unavailable
exceptions?
NetBSD already does that.
If so, then you just need to be careful to flush the FP/AltiVec state
(if any exists: look in MSR) before using the FP/AltiVrec registers.
In the Linux/PPC64 kernel, we require all FP use in the kernel to
excplitly flush the FP state and enable FP mode before any FP use.
We enforce that by panic'ing on a FP Unavailable exception that comes
from kernel state.... we've have problems with driver writers not
using -msoft-float during tere builds and it was causing data integrity
errors in userland code.
You could do that if you wanted to use AltiVec in the kernel. But that
could be a lot of overhead if there is significant use of AltiVec in the
kernel. The use of FP in the kernel will be significantly less common
than the use of AltiVec.
NetBSD already uses AltiVec for doing VM page zeros (without polluting
the cache) and VM page copies. I also have AltiVec versions of in_cksum,
memcpy, and some of the str* routines. All of these are significantly
faster than the non-AltiVec implementations.
Since most of the routines use a few altivec registers (2..6), it seems
to me that it's much less overhead to save/restore these on a per-routine
basis that to save the AltiVec state and then take an exception to restore
it.
--
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