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