Re: [ECOS] FPU support implementation question.

[Sergei Organov <osv at javad dot ru>]

"Patrick O'Grady" <patrick@softprocess.com> writes:
> When I did the FPU handling on the x86, I made a couple of decisions which
> may help you:
> 
> - Save the FPU context at the unused end of the thread's stack.  In the
> case of the X86, the unused part of the stack is at the lowest address. I
> kept track of who last used the FPU, so when another thread wanted to use
> it, I could stash the context there, along with a signature word which
> indicates that the FPU context is valid.  It may help to check out FPU
> support in the x86 HAL (packages/hal/i386/pc/current/src/plf_misc.c)...

Thanks, this is exactly how I'm going to do it, but I thought that only MIPS
hal has FPU support. It's definitely helpful to have a hal where it's already
implemented. Could you please clarify a few more things (simple yes/no would
be enough):

1. Do you always disable FPU in the CPU context switch code and switch FPU
   context in the interrupt handler only?

2. Is it allowed to use FPU in ISRs? In DSRs?

> - Don't make it configurable.  The hardware should only generate
> interrupts if you enable it (which should be always) AND when a thread
> tries to use the FPU... that way an application can enable or disable this
> mode automatically.  My experience is that if you allow someone to
> configure it, they'll mess it up, and that two years later, when a
> customer says, 'well, I only want to perform one operation...' that you
> don't have to rebuild the OS...

Well, making something configurable never comes for free. I believe the best
way is to have this mode enabled by default, but leave possibility to turn it
to full non-lazy FP context switch. The latter could be useful for debugging.

Also some time ago there was discussion about related configuration options,
and decision was made that we better make it configurable.

> 
> HTH--cheers!
> 
> -patrick

BR,
Sergei.

> 
> 
> 
> On 11 Apr 2000, Sergei Organov wrote:
> 
> > Hello,
> > 
> > I'm implementing FPU support in the PowerPC HAL and have a design dilemma that 
> > I'd like to discuss.
> > 
> > I have working version that is modeled after the MIPS HAL. Now I'd like to
> > start to implement advanced FPU support that will switch FPU context on
> > demand. This requires that FPU state is stored not in the CPU context as it is
> > now, but in some other place that is pointed to from the CPU context. The
> > on-demand FPU context switch will be a configuration option, and if it is
> > disabled, then current simple implementation is active. For simplicity I'd
> > like to still save FPU context outside of CPU contex even if the on-demand
> > option is disabled. Compared to the current implementation this approach adds
> > additional overhead of dereferencing pointer on every context save and
> > restore. I believe the overhead is actually small and could be ignored.
> > 
> > Any comments?
> > 
> > Thanks,
> > Sergei.
> > 
> >