Heikki Lindholm wrote:
 > Yes, Altivec is separate from the FPU. Hopefully nobody uses FPU in the 
 > kernel - AFAIK currently not, but you never know about closed-source 
 > drivers and such. Whereas, Altivec, I think, is something that should, 
 > eventually, be supported by the real-time domain, too. Adding Altivec 
 > support is very similar to the existing fpu support, and being that it 
 > has to tackle the kernel-using-altivec issue anyway, it's probably nicer 
 > to add fpu kernel support as well. Only problem is that it will increase 
 > the context switch time. 

Maybe we could add an XNSIMD flag for Altivec and SSE, distinct from
XNFPU, so that only the task that really use SIMD instructions would pay
the price of the switch ?

 > I'd remember that using the FPU bits (instead 
 > of task state) from the processor will pretty much cause saving state on 
 > every transition to xeno, because of the kernel's lazy usage model (on 
 > UP; SMP will do that anyway).

I do not understand what you mean: on x86 the state of the ts bit in cr0
is enough to know if the FPU was used either in kernel-space or in
user-space. I know power pc is a bit different because the state of the
FPU is saved by the user/kernel switches, but is not the state of the
MSR_FP bit enough to know if FPU was used in kernel-space ?


                                            Gilles Chanteperdrix.

Xenomai-core mailing list

Reply via email to