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

[Al Viro]

On Tue, Jun 24, 2014 at 11:33:32AM -0700, Richard Henderson wrote:
> >         return (unsigned long)x;        // SVCTQ/SVC
                                               CVTTQ/SVC, of course...
> Clearly a gross misunderstanding of what bits are actually computed, never 
> mind
> what gets signaled.
> 
> Thanks for the test.  I've not had working hardware for a couple of years to
> validate what's supposed to get set and what isn't.

If you have any ideas for testing, I do have working hw (the box that is
currently alive is ev45, though; I _can_ try to boot a UP1000 one, but
I make no promises regarding its fans, both in PSU and in CPU module ;-/)

> > Can't we simply have separate helpers for various trap suffices, with
> > all this work on getting exc, etc. taken inside them?  It's not as if
> > we distinguished many variants, after all...  Right now we have:
> >     plain, /U, /V
> >     /S, /SU
> >     /SUI
> >     /SV
> >     /SVI
> 
> We used to have separate helpers... at least for the modes that had been
> implemented at the time.  The combinatorial explosion ugly though -- 4
> different versions of add, sub, etc.  I thought the partial inlining was a
> decent solution, as far as maintainability, but it's not unreasonable to 
> disagree.

Um?  No, I mean having gen_fp_exc_raise() generate a call of one of the 8
helpers; gen_ieee_arith3() and friends would remain as-is.  It's just that
instead of generating load to exc, andi, call of helper_fp_exc_raise_s or
call of helper_fp_exc_raise we would generate a call of one of the
helper_fp_exc_raise{,_u,_v,_s,_su,_sui,_sv,_svi} and let that sucker deal
with loading exc, updating ->fpcr_exc_status and generating traps.

> > Another thing: shouldn't arithmetics on denorms without /S raise EXC_M_INV,
> > rather than EXC_M_UNF?
> 
> No idea.  Should they?

They seem to - both from the arch.manual and from direct experiment...  And
they do set FPCR.INV at the same time, not just trigger the trap.