On 07/05/2014 03:55 PM, Al Viro wrote:
> +/* Input handing with software completion. Trap for denorms,
> + unless DNZ is set. *IF* we try to support DNOD (which
> + none of the produced hardware did, AFAICS), we'll need
> + to suppress the trap when FPCR.DNOD is set; then the
> + code downstream of that will need to cope with denorms
> + sans flush_input_to_zero. Most of it should work sanely,
> + but there's nothing to compare with...
> +*/
> +void helper_ieee_input_s(CPUAlphaState *env, uint64_t val)
> +{
> + if (unlikely(2 * val - 1 < 0x1fffffffffffff)) {
> + if (!FP_STATUS.flush_inputs_to_zero) {
> + arith_excp(env, GETPC(), EXC_M_INV | EXC_M_SWC, 0);
> + }
> + }
> +}
> +
A couple of points here:
1) We should never raise this in user-only mode. In that mode, we emulate the
whole fpu stack, all the way through from HW to the OS completion handler.
2) Because of that, we have the capability of doing the same thing in system
mode. This lets us do more of the computation in the host, and less in the
guest, which is faster. The only thing this makes more difficult is debugging
the OS completion handlers within the kernel, since they'll only get invoked
when SIGFPE needs to be sent.
3) If we do want to implement a mode where we faithfully send SWC for all of
the bits of IEEE that real HW didn't implement, do we really need to avoid a
store to the output register when signalling this? I.e. can we notice this
condition after the fact with float_flag_input_denormal, rather than having
another function call to prep the inputs?
r~
