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.


Sergei Organov <osv@javad.ru> writes:

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

Actually, what I think I meant was that if the interrupt had not used
the FPU, but the thread was using it, then we should re-set (not
clear) the FP enable bit on exit. If the interrupt has not used the
FPU then is still contains the thread's FP state, so setting the bit
will avoid the subsequent FP trap. Obviously some care needs to be
taken not to set the bit spuriously if interrupt_end() had caused a
thread switch.

> What "interrupt entry" and
> "interrupt return" mean exactly, - before/after call to particular ISR, or
> begin/end of the default VSR handler?

I meant the VSR handler code.

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

An ISR is allowed to enable its own interrupt, either in
the hardware it controls, or in the interrupt controller, but
shouldn't enable interrupts globally.

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

I suspect that this is the best approach to this problem. At least for
the present, or until someone works out how to do it properly. I would
much rather not provide a facility than supply a badly thought-out or
poorly implemented version.

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


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