This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: On demand FP context switch major problem.


Nick Garnett <nickg@cygnus.co.uk> writes:
> Sergei Organov <osv@javad.ru> writes:
>
> The management of the memory for storing nested FP contexts is a
> little involved but not impossible. The main problem is the management
> of the FP enable bit. I think that the general approach here would be
> to disable the FPU on interrupt entry, take FPU traps as normal during
> interrupt processing and on interrupt return decide whether the FPU
> had been used, and if not, clear the FP bit. The interrupt's FPU
> context at this point is redundant, so it can just be overwritten.

If FPU hadn't been used, then FP bit is still cleared on interrupt return, so
there is no reason to clear it again. Did you mean that FP bit should be
cleared on exit from ISR if FPU had been used? What "interrupt entry" and
"interrupt return" mean exactly, - before/after call to particular ISR, or
begin/end of the default VSR handler?

I must say that I still don't see how to handle FP bit if FPU usage in
ISRs/DSRs is enabled. While situation with HAL_DISABLE_INTERRUPTS is now
resolved (just clear FP bit), the following places have troubles:

1. hal_cpu_int_merge at the end of hal_thread_switch_context.
2. hal_cpu_int_merge at the end of hal_interrupt_stack_call_pending_DSRs.
3. hal_cpu_int_disable at the end of cyg_hal_default_interrupt_vsr.
4. a few places where FP bit is changed (added to support on-demand FP).

If FP usage in ISRs/DSRs is disabled, all these places don't have troubles
because scheduler is locked there, and thus interrupts will not change the FP
bit. If FP usage in ISRs/DSRs is enabled, then possibility that interrupt will
clear FP bit exists, and we can't safely modify MSR even if scheduler is
locked. We also can't clear FP bit there because this will result in a lot of
"FP unavailable" traps.  While these traps will not actually switch context
most of time, they still have overhead.

As you wrote in previous mail, in the case (3) interrupts are already disabled
when we return from interrupt, so there is no reason to disable them again. I
guess that's because they are merged in (1). But what if interrupts are
re-enabled inside the ISR? Or is it prohibited to enable interrupts in ISR
handlers?

Anyway, (1), (2), and (4) still have troubles, I think.

> > Is the capability to use FP in ISRs/DSRs significant enough to deny on-demand
> > context switch implementation on the PowerPC?
>
> I think we can expect writers of ISRs and DSRs to be reasonably
> disciplined and to avoid any FP code. So banning FP use in these
> contexts is not a major problem. The main area of worry is in the
> alarm handler routines. At present these are called from a DSR and may
> contain any user code. We can impose the same restrictions on these
> functions as on DSRs, but it would be nice to lift it one day. One
> approach to this is to move alarm handling to a proper thread
> context, but this is still in the future.

Possibility to configure eCos to use simple variant of FP context switch still
remains. If application requires FPU even in ISRs/DSRs/alarm handlers, then
it's likely that most of tasks require FPU as well, so there is no reason to
use on-demand context switch implementation that has some overhead anyway.

>
>
> --
> Nick Garnett
> Cygnus Solutions, a Red Hat Company
> Cambridge, UK

BR,
Sergei Organov.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]