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: 01 Jun 2000 13:36:12 +0400
- Cc: ecos-discuss at sourceware dot cygnus dot com
- References: <87u2fwt559.fsf@osv.javad.ru> <poaehohucn.fsf@balti.cygnus.co.uk> <87puqjt0p5.fsf@osv.javad.ru> <877lcarg0h.fsf@osv.javad.ru> <povgzure5w.fsf@balti.cygnus.co.uk>
I agree with your (random) thoughts. However for me it seems that on-demand
context switch is incompatible with ability to use of the floating point in
ISRs/DSRs. I actually even didn't start to try to implement this capability
when on-demand FP context switch is configured, but it seems that if
implemented, then *any* interrupt could clear FP bit in MSR, and thus the fact
that scheduler is locked in the DSR code doesn't help :-(
Is the capability to use FP in ISRs/DSRs significant enough to deny on-demand
context switch implementation on the PowerPC?
Nick Garnett <nickg@cygnus.co.uk> writes:
> Sergei Organov <osv@javad.ru> writes:
>
> > Nick,
> >
> > I was very busy last two weeks, but now when I've got a chance to return to
> > the FP implementation, I've found another related problem.
> >
> > The default interrupt handler calls 'hal_cpu_int_disable' close to the end of
> > the ISR processing. If I disable FP there, then *every* interrupt will result
> > in disabling of FP, that is obviously unacceptable.
> >
> > Yet another similar place is in the
> > 'hal_interrupt_stack_call_pending_DSRs' that restores interrupt settings
> > before return.
> >
> > Do you see a way to handle above cases?
>
>
> I haven't thought a lot of this through, but here are some (random)
> thoughts:
>
> There is no reason why the asm level macros should behave the same way
> as the user level ones do. These are all used in very specialized
> places where it may not matter. Looking at the code,apart from the
> merge in context.S, these are only used in the places you mention in
> vectors.S.
>
> The disable in restore_state only actually disables interrupts when
> returning from an exception. When returning from an interrupt, they
> are already disabled at this point. Perhaps the disable should be
> taken out of here and put into a path that only the exception code
> will go through.
>
> Perhaps the macros should only clear the FP enable if they actually
> change the interrupt state.
>
> In the DSR code, we know that any interrupt that occurs will not cause
> a thread switch, since the scheduler lock is non-zero. Hence the FPU
> state will not have changed. So I don't think we have to clear the FP
> enable at all through this code.
>
>
> --
> Nick Garnett
> Cygnus Solutions, a Red Hat Company
> Cambridge, UK