This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: On demand FP context switch major problem.
- To: Nick Garnett <nickg at cygnus dot co dot uk>
- Subject: Re: [ECOS] On demand FP context switch major problem.
- From: Sergei Organov <osv at javad dot ru>
- Date: 19 May 2000 12:15:50 +0400
- Cc: ecos-discuss at sourceware dot cygnus dot com
- References: <87u2fwt559.fsf@osv.javad.ru> <poaehohucn.fsf@balti.cygnus.co.uk>
Nick,
What you suggest seems to be the most reasonable (if not the only) solution to
the problem.
Thanks,
Sergei.
Nick Garnett <nickg@cygnus.co.uk> writes:
> Sergei Organov <osv@javad.ru> writes:
[...]
> This is one of the annoying features of the PowerPC, and other RISC
> processors, that "global" state and "per-thread" state are mixed up in
> the same register.
>
> One option would be to always clear the FP enable bit in
> HAL_DISABLE_INTERRUPTS (probably HAL_ENABLE_INTERRUPTS and
> HAL_RESTORE_INTERRUPTS too). This would make your described scenario
> work correctly since you would get an FP exception at step 7. In the
> simple case you would also get an FP trap on the next FP instruction,
> which would see that the current thread is already the FPU owner and
> just set the FP enable bit.
>
> Taking the extra trap is unpleasant, but with a suitable fast path it
> should not be too expensive. It is unlikely that code which plays with
> the interrupt enable is also doing a lot of floating point, and the
> thread may well be timesliced or preempted before moving from one to
> the other anyway. So the chances are that this will not result in any
> more FP traps than before. There has to be a FP trap per thread switch
> anyway, and changing the interrupt enable should be a lot less common
> than that.
>
>
>
> --
> Nick Garnett
> Cygnus Solutions, a Red Hat Company
> Cambridge, UK