Subject: Re: Floating point traps
To: None <dall@hfrd.dsto.gov.au>
From: Jon Buller <jonb@metronet.com>
List: port-pc532
Date: 08/23/1995 07:10:31
I'll try to shed a small ember's worth of light on this, I went poking
into the same problem about a couple of months ago.
> With lites for the pc532, I have a problem with floating point
> traps. When a floating point trap happens, the pc points at the
> instruction which faulted. Most processes just core dump on a SIGFPE,
> so there is no problem, but recently I discovered that if a process
> trys to either catch or ignore SIGFPEs, then the execution takes the
> same trap immediately. Hence, you get stuck infinitely repeating the
> same trap.
Ugh, never realized this. Sounds like some work is needed in trap.c
> Ideally, one should use the trap to optionally emulate the correct
> ieee operation. There are several commercial unixes which allow you
> to, for example, get a SIGFPE on a floating divide by zero or have
> +-Infinity generated as per the ieee spec. It seems to me that to do
> this, one needs to decode the instruction and its operands, optionally
> emulate the correct behaviour and position the pc at the end of the
> instruction. If you do enough to emulate all the correct behaviour,
> including denorms, then you have pretty much written a complete ieee
> emulator which would be nice to have.
I was trying to get the simple result of getting +-Inf on a multiply
overflow, and pretty much came to the conclusion that this particular
case was very easy, except that to get the sign bit correct, I'd
need the operands, which requires... I believe that it may be
possible to copy the 5 operand bits out of an instruction that
faulted, and put them into a 'move gen,R0' instruction (or the
like) and run that to get the operands. But this might have problems
with tos addressing, by moving the stackpointer twice as much as
it should for one operand, messing everything else up badly. At
this point I gave up, since I didn't want to think of how much code
it might be to properly simulate the whole FP set of instructions
and their million and one combinations of addressing modes.
Let me know if you find out anything, I'm interested, and may be
able to offer a little bit of help along the way.
Jon