> Part of this might be resolved by better processing in pc532/pc532/trap.c.
> I didn't do very much work on the fpe traps.  I just sent them to
> signals.  It might be appropriate to look at the trap and see what caused
> it and then make a decision as to what to do.  We (I? you? ???) should
> look at what generates the FPE traps and then decide what the best
> action to take based on what caused the FPE trap.

Well, I'd be glad to take a shot at it, but I have no idea what I'm doing
once I get on the other side of a syscall (or deeply into the libraries
for that matter).  I think I have a reasonable feel for what should happen,
but I may have some difficulty climbing the learning curve for deeper
system stuff.

After looking at trap.c, I was wondering if all the trap code gets is
the registers.  The particular case I was looking at was multiply
overflow, and all that's needed is to detect the exception and replace
the result with Inf.  The only problem is that I need both args to
determine the sign bit, and they can be general operands, so will I
need to parse the instruction at the PC location, determine both
operands, get the results of the operand fetchs, then do the easy part
of computing the sign bit, and stuffing the result back in the second
operand?  That seems like a LOT of work.  Has it already been done, or
is there some magic way to avoid all that?

All hints and suggestions welcome,
Jon