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.
