HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (05/03/90)
Due to my considerations, the following it the best approach: - allow inline FPU code: this is the best way to exploit the FPU advantages - therefore, you need space in the process table so you can save the FPU status (the whole status, not only the FPU registers!) -- but this are only a few KBytes, so it does not matter. - it is a waste of time to save the FPU status of a process which doesn't use the FPU. Since you have to tell cc that the code contains floating point (to link the code with libm.a) - let cc select a special version of the startup-code crtso.o which tells the kernel somehow that this code is going to use floating point. This sets a flag in the process table so upon a task switch, the kernel can decide if FPU status has to be saved or restored. Only disadvantage: if you fork a shell from a program using floating point, all children save the FPU status. But this doesn't matter. - All the processes which don't have the FPU Flag set in the process table can be scheduled as quick as if there were no FPU. - Any comments/suggestions? Christoph van Wuellen.