Re: FPU Management for VSTa

[Tan Pong Heng <tponghen@Trantor.DSO.gov.SG> writes:]

>... I realized that the
>kernel saved the state of the FPU everytime it does a task switch!

Nope, shouldn't. Are you sure you read it right? You need to take a look
at when T_FPU is set in the thread flags. It's set in trap.c when an access
is attempted to the FPU. A non-FPU process will never execute an FPU
instruction, will never get the bit turned on, and will run at full speed.
In sched.c all the code to do an FPU save is conditional on T_FPU.

A process which accesses a couple FPU instructions, switches away, and
doesn't execute any more will also not have T_FPU set the 2nd and successive
times it runs.

> The Linux used a smarter scheme that it would
>save the old state when a new task starts to use the FPU and caused a
>FPU exception due to the TS bit.

Except this has serious problems in a multiprocessor environment. It's
really, really hard to grab CPU state out from under another CPU without
having a performance hit at best, and nasy bugs indeed at worst. Since FPU
isn't famous for being all that fast, I wanted to move what "hit" there was
to the FPU-using process.

>... I hope this scheme
>would be implemented in the next release of VSTa.

Nope, I'd rather leave things compatible with multiprocessor hardware.
There are a couple groups who are looking at such ports, so it'll be more
than academic with a little luck.

                                                Regards,
                                                Andy
Received on Sun Oct 9 20:00:59 1994