Re: [ECOS] FPU support implementation question.

["Patrick O'Grady" <patrick at softprocess dot com>]

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)...

- 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...

HTH--cheers!

-patrick



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.
> 
>