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

[Al Viro <viro@ZenIV.linux.org.uk>]

On Wed, Jul 09, 2014 at 08:14:12AM -0700, Richard Henderson wrote:
> On 07/08/2014 10:47 PM, Al Viro wrote:
> > So env->fpcr_flush_to_zero = env->fpcr_dnod & env->fpcr_undz; is another
> > bug - needs s/dnod/unfd/ there...
> 
> That's exactly what I was looking at, thanks.

BTW, that (unimplementeds being RAZ) is why AARM insists on having FP_C in
software - FPCR isn't guaranteed to have the "trap disable" bits and, in fact,
doesn't have anywhere to store IEEE_TRAP_ENABLE_DNO on actual hw.  The
software completion is where it has to be dealt with; note that both
swcr_update_status() and ieee_swcr_to_fpcr() treat ->ieee_state (i.e. our FP_C)
as authoritative wrt trap enable bits, 21264 or not.  Trap _status_ bits are
different - there (on 21264) FPCR is considered authoritative, but that's it.

Unimplemented trap bits are treated as "trap enabled", so the completion gets
to decide what it wants to do.  If you want to keep FPCR authoritative for
all those bits in linux-user case, we have to treat FPCR.DNOD as writable
bit for that mode, which is why my variant slapped an ifdef CONFIG_USER_ONLY
around 
     env->fpcr_dnod = (val & FPCR_DNOD) != 0;
instead of ripping it out completely...