Detecting thread's use of FPU

[NickJohnson]

I currently have it in my OS so the FPU is always saved and loaded (assuming it exists) when a thread switch occurs, but I want to optimize it so threads that are not using the FPU do not take up time and space with FPU saving/loading. Can I reliably detect whether a thread is using the FPU by setting a "using FPU" flag when I catch any floating point exception from the thread? When I catch that FPE, do I have to do anything to make sure the thread will not lose data, or will returning from the exception set the instruction pointer to retry the FPU operation?

[FlashBurn]

Have a look at the TS, EM and MP flags of cr0 in the intel manuals. There is all you want to know!

[NickJohnson]

So what I understand from the manuals (assuming EM is not set) is that I should check the TS flag in CR0 when doing a thread switch to see whether the FPU was used, and therefore if its state should be saved, and then clear the TS flag using CLTS. Is that right?

Edit:
Scratch that, it was totally wrong. Is it that you set TS after every thread switch, wait for a #NM, at which time you set a "save FPU" flag in the thread, then when switching threads again, save only if that flag is set and clear that flag?

[FlashBurn]

Not really

1st it makes a difference if your kernel runs on 1 cpu systems or multi cpu systems.

For 1 cpu systems you set the TS flag with every thread switch. If the exception is called you 1st CLTS and save the fpu context for the last thread which was using the fpu (or if this is NULL you needn´t to do that) and then you load the fpu context of the current thread.
So for 1 cpu systems you can make lazy fpu loading and saving.

For multi cpu systems you also set the TS flag with every thread switch. If the exception is called you 1st CLTS and load the fpu context for the current thread. Now you also need to save the fpu context if the TS flag is clear with every thread switch!

So I hope I made it clear, if not ask!

[NickJohnson]

I think I understand now. I was actually thinking only about optimizing out unneeded saves, but this method seems to get rid of unneeded saves and loads, which makes more sense. It seems like the 1-CPU option is trickier, because you need to keep track of the previous thread at all times, so I'd probably go with something more like the multi-CPU option even though I'm not using more than one CPU - it doesn't seem like "lazy" saving has an advantage over "eager" saving on thread switches: saving still only happens when the thread has used the FPU during its timeslice.

Thanks for the advice!

[FlashBurn]

The point is imagine you have only 1 thread which is using the FPU (like a game) and if you would use also lazy saving, you would never save the fpu context (which is not really fast) and all you have to do is, have a pointer (and maybe a checksum or some other control value) for the thread which used the fpu last time.

[NickJohnson]

I suppose, but I'd prefer simplicity over the elimination of a microsecond overhead every two dozen thread switches, at least until my OS is more complete and I can work on smaller optimizations like that.