Re: PPC AltiVec request: add an abi variant

[Peter Bergner <peter at bergner dot org>]

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?

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.


Peter