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: Wed, 31 May 2000 06:44:00 -0000 Message-id: <877lcarg0h.fsf@osv.javad.ru> References: <87u2fwt559.fsf@osv.javad.ru> <87puqjt0p5.fsf@osv.javad.ru> X-SW-Source: 2000-05/msg00269.html 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 writes: > Nick, > > What you suggest seems to be the most reasonable (if not the only) solution > to the problem. > > Thanks, > Sergei. > > Nick Garnett writes: > > Sergei Organov 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