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,

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?

BR,
Sergei.

Sergei Organov <osv@javad.ru> writes:
> 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


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