Phil Nelson <phil@cs.wwu.edu> writes:

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

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

I pretty much have a working solution to this. Currently it runs as a
signal handler for debugging and is still little tested. Basically,
it decodes the instruction. simulates the correct action (including
handling denorms and generating them on underflow). There are some bits
in the fsr available for software emulations to use and I use these to
enable and flag various things (like whether to pass divide by zero
to the users trap handler or to generate +-Inf).

I have been slightly diverted by discovering some lites signal bugs which
cause my code to work inconsistently. (ie exact same program and data, but
behaves differently on different runs).

Anyway, I expect to make this available soon. I want to be able to
optionally compile for either a user mode signal handler or a mach
micro kernel trap handler. I'd imagine that it would be trivial to
also make it work for netbsd.

Ian

-- 
Ian Dall          I'm not into isms, but hedonism is the most
                  harmless I can think of. -- Phillip Adams

internet: dall@hfrd.dsto.gov.au