From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Organov To: Nick Garnett Cc: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] On demand FP context switch major problem. Date: Thu, 01 Jun 2000 02:36:00 -0000 Message-id: <874s7dpwtv.fsf@osv.javad.ru> References: <87u2fwt559.fsf@osv.javad.ru> <87puqjt0p5.fsf@osv.javad.ru> <877lcarg0h.fsf@osv.javad.ru> X-SW-Source: 2000-06/msg00000.html 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 writes: > Sergei Organov 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