On Fri, 14 Dec 2007, Tom wrote:

> Any ideas on the best way to deal with AI (illegal floating point operation)
> exceptions?  I can trap them, but then what?  For example, I set up a break
> point in a dummy exception handler, and I found 3 registers with NANs in
> them.  But how to know which register triggered the AI, as perhaps one or
> two of the registers were using integer rather than floating point (and thus
> did not contain NANs)?

there are several ways to deal with it.  One is at a "global" level, the
other is at an execution level.

For global level you just set a flag that a process or subroutine has
failed.  check the flag at the end of the process or return from
subroutine, and if an AI happened, throw out the whole result.  this
maintains timing usually since you are not short cutting the whole
calculation.  It's also an attitude - you don't care why things failed,
you just note that they did.

At the execution level, you grab the return address from the stack
(usually a special instruction since DSP's have special interrupt stacks)
and use it as a lookup to figure out which routine or set of instructions
you were particularly worried about.  If you know that exceptions can
occur in just a few places you can check which place you were in and deal
with it explicitly.  Otherwise, you can use it for debugging and mark the
return address so you can to a post mortum to help figure out how to
prevent it from happening again.

It takes more time to figure out why things can fail, and then you have to
look for the conditions which cause failure in the first place.  That
takes processor time.  If you don't have a lot of spare clocks, sometimes
ignoring results is the best way to deal with things.

Patience, persistence, truth,
Dr. mike