On Fri, 18 Sep 1998, Brian C. Grayson wrote:

> On Fri, Sep 18, 1998 at 08:52:34AM -0700, Chris G. Demetriou wrote:
> > gson@araneus.fi (Andreas Gustafsson) writes:
> > 
> > > So, I am wondering, is this lack of support for floating point in the
> > > kernel on the i386 port
> > > 
> > >  a) considered a bug or a feature?
> > 
> > Feature.  It's a performance issue:
> > 
> > If you can use FP in the kernel, then unless you're very careful about
> > saves and restores around the places where you want to do FP work, you
> > need to save FP state in every interrupt and trap entry and exit
> > routine.
> 
>   I don't know what I'm talking about :), but since the use of FP
> is going to be rare, would something based on the following
> work (after suitable extension to cover all the potential
> problems I'm missing, like avoiding corrupting the user's FP
> registers?):
> 
>   a)  upon entry into any device routines that use FP, you first
>       increment global_using_fpregs.
>   b)  upon exit from any device routines that use FP, you
>       decrement global_using_fpregs (and panic if it is already
>       zero).
>   c)  in the main interrupt handler, if global_using_fpregs > 0,
>       save the FP registers, otherwise you don't have to.
> 
	I could be missing something here, but since nothing currently in
	the kernel uses FPU, and all we have to preserve is user data
	in FPU registers then if you are not using them in an interrupt
	context, you can just save and restore around each use of the
	registers? In a threaded kernel you could use a mutex lock to
	ensure it all works.

	Then you could conditionally compile in the code that uses the FPU
	without needing to modify any other part of the kernel.

	Obviously you need to ensure there is an FPU present, plus pay the
	code for the saves/restores appropriately...

		David/absolute

	Abandoning a syncing disk... or syncing an abandoned disk?