Why _ThreadProcessSignalsFromIrq() in new exception processing?

[gregory.menke at gsfc.nasa.gov]

Joel Sherrill writes:
 > 
 > 
 > Sergei Organov wrote:
 > > 
 > 
 > I would think so since an exception handler might be used to implement
 > missing instructions.  In this case, the handler would have to tinker
 > with
 > the values of any register touched by the unimplemented instruction.
 > 
 > Similarly, in some cases, FPU exceptions have to clean up the results
 > and fix registers before returning.  I recall Greg Menke saying the
 > MIPS FPU exception code from NetBSD was pretty ugly.  The MIPS stack
 > frame from RTEMS in compatable with that one.  

The code itself isn't so horrible, but what it has to do is.  For some
exceptions, the handler has to do back to the instruction that threw,
disassemble it, then do the arithmetic & generate the output, then
return.  Pretty much nothing short of a full stack frame will do for
the routine, though it is incrementally assembled as control routes to
the fpu exception code.  This is for the R3000- later processors
presumably have a better FPU for which some of the overhead could be
avoided.

 > 
 > > 3. Is the difference (D2) a bug? If yes, the bug in the former code or in
 > >    the later?
 > 
 > I don't think the FP context is ever saved on any interrupt or exception
 > path by RTEMS.  It is assumed that if the handler needs the FP context,
 > it will deal with it itself.  This could literally adds 100s of CPU
 > cycles on some architectures.  
 > 

The MIPS exception handler will save/restore fpu context on entry and
exit in order to give the gdb stub a coherent set of fpu registers.
It costs just over 64 cycles in and 64 cycles out.

Gregm