Re: [ros-dev] Save FPU on task switch/SSE support

[Gregor Anich]

Hartmut Birr wrote:

>  We can do the same for sse. If sse is available we must
> use fxsave/fxrstor
> instead of fsave/frstor and the buffer is 512 byte (108 byte for normal
> fpu).
>
> - Hartmut
>   
>  
Hi!

I have thought about it a bit more and talked to tamlin a bit... now 
here's how I think some things should be done... and some things which i 
am not sure about...

1) Initialize NpxState of KTHREAD to cr0 & MP | TS | EM in 
Ke386InitThreadWithContext (maybe in Ke386InitThread too? I don't think 
so...) and change FLOATING_SAVE_AREA to FX_SAVE_AREA in that function - 
ke/i386/thread.c
2) in Ki386ContextSwitch we save cr0 & MP | TS | EM into the old 
thread's NpxState, and put the NpxState of the new thread or'ed with TS 
into cr0 (this could be skipped, we could just set TS unless there was a 
reason to run some processes with EM set and some without; MP should 
never change I think - but this way is safer) - ke/i386/tskswitch.S
3) in KiTrapHandler handle the device-not-present exception in a special 
way if TS in cr0 is set (or maybe assert that TS is set?) - can the 
device-not-present fault happen for non-FPU /SEE/MMX code? - ke/i386/exp.c

I am not sure when to save the FPU state... I think it has to be saved 
when the thread enters Ki386ContextSwitch and if TS is not set - this 
means the thread has used the FPU. Then the new thread will run, TS is 
set and the first FPU code will get into KiTrapHandler, where we handle 
it in a special way - we restore the previous (or initial) FPU state 
(FX_SAVE_AREA) from the kernel stack top, unset TS and let the thread 
run until it reaches Ki386ContextSwitch again where the FPU state will 
be saved if TS is unset.

Just bad that we will always have to save it if it was used I think, 
even if no other program uses it. First I thought maybe we could save 
the state of the old thread in the exception handler for the new threads 
first opcode (somewhere the previous thread is saved, isnt it?) and then 
restore the new thread's previous state - but this wouldnt work if one 
thread used the FPU, it switched to another (which doesnt use the FPU) 
and then to yet another which uses the FPU - the previous thread would 
then not be the first but the second thread which didnt use FPU)

I'd appreciate some comments on this.

Thanks,
  blight