On Mon, Jul 07, 2014 at 09:20:28AM -0700, Richard Henderson wrote:
> > 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.
Umm... Not quite. Consider e.g. CVTQL case. There we have the following
picture in case of overflow (real hw with Linux on top of it):
no suffix: IOV INE
/v: IOV INE SIGFPE
/sv, no IEEE INVE: IOV INE INV
/sv, IEEE INVE: IOV INE INV SIGFPE
This is after the completion had a chance to run. From the hw POV it's
no suffix IOV INE no trap
/v IOV INE trap<IOV>
/sv IOV INE trap<SWC,IOV>
and it's alpha_fp_emul() that does the rest in /sv case. Actually, it's even
simpler:
if overflow
FPCR.INE = 1
raise IOV
do usual trap suffix handling
and I'm reasonably sure that this is what they did internally. You are
proposing to do 4 cases in all their messy glory in qemu itself...
And I wouldn't bet a dime on not having similar turds in other insns; after
all, "it's hard, let's offload it to software" was only a part of motivation
for software completions. "We really don't like this part of IEEE standard
and we'd love to tell you to see figure 1, but we need conformance, so you
can mark an insn with /s and have the kernel do what IEEE requires" is also
very visible in their manual.
Result is a mess - if you try to fold the kernel-side stuff into "hardware",
you end up with a pile of inconsistent behaviours. In principle, it's
doable, especially since we are not really constrained by actual hw in terms
of what we do in case of FPCR.DNOD being true - no actual hw could set it.
So we want
* hw behaviour without /s (denorms trap)
* hw behaviour with /s without denorms
* hw behaviour with /s with denorms with FPCR.DNZ (same as with 0)
* kernel completion behaviour with /s with denorm
and it might even be what they intended for DNOD to do. But it's going
to be messy as hell.
And that's not even going into generating the right si_code for that SIGFPE.
What produces those TARGET_GEN_FLTINE and friends?
