Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions

[Richard Henderson]

On 07/07/2014 08:06 AM, Al Viro wrote:
> On Mon, Jul 07, 2014 at 07:11:58AM -0700, Richard Henderson wrote:
>> 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.
> 
> How is that different from other cases where we have an exception raised
> by an fp operation?

In all other cases we know we're going to send SIGFPE.  That's either through a
non /S insn which the kernel wouldn't touch, or by having computed the true
IEEE result and examined the exceptions to be raised.

>> 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.
> 
> Umm...  The effect of software completion depends on current->ieee_state;
> how would you keep track of that outside of guest kernel?

The kernel essentially keeps a copy of IEEE_STATE in the FPCR.  I don't see any
missing bits in ieee_swcr_to_fpcr, do you?

While real hardware might ignore some of those bits once stored, qemu doesn't.

While in real hardware one could force the FPCR and IEEE_STATE to differ,
honestly that'd be a bug.  (Although a silly one; I wish the kernel took the
EV6 FPCR as gospel for everything, not just the status flags.  That could make
certain libm.so computations much faster.)

> 
>> 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?
> 
> But flag_input_denormal is raised only when we do have DNZ set.  Which is
> an entirely different case, where we should not (and do not) get an exception
> at all...

Ah, you're right about that.  I'd mis-remembered the implementation.


r~