From: user5857@newsgrouper.org.invalid
kegs@provalid.com (Kent Dickey) posted:
> In article <1763868010-5857@newsgrouper.org>,
> MitchAlsup wrote:
> >
> >Robert Finch posted:
> >> My float package puts the cause in the 3 LoBs. The cause is always in
> >> the low order bits of the register then, even when the precision is
> >> different. But the address is not tracked. The package does not have
> >> access to the address. Seems like NaN trace hardware might be useful.
> >
> >Suggest you read::
> >https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/ba
kground/nan-propagation.pdf
> >For conversation about LoBs versus HoBs.
>
> I wasn't sure where to join the NaN conversation, but this seems like a
> good spot.
>
> We've had 40+ years of different architectures handling NaNs, (what to
> encode in them to indicate where the first problem occurred) and all
> architectures do something different when operating on two NaNs:
>
> From that paper:
> - Intel using x87 instructions: NaN2 if both quiet, NaN1 if NaN2 is
signalling
> - Intel using SSE instructions: NaN1
> - AMD using x87 instructions: NaN2
> - AMD using SSE instructions: NaN1
> - IBM Power PC: NaN1
> - IBM Z mainframe: NaN1 if both quiet, [precedence] to signalling NaN
> - ARM: NaN1 if both quiet, [precedence] to signalling NaN
>
> And adding one more not in that paper:
> - RISC-V: Always returns canonical NaN only, for Single: 0x7fc00000
>
> I'll just say whatever your NaN handling is, for the source code:
>
> A = B + C + D + E
>
> then for whatever values B,C,D,E having NaN or not, the value of A should
> be well defined and not dependent on the order of operations.
I nice philosophy, but how does one achieve that when the compiler is allowed
to encode the above as::
A = (B+C)+(D+E)
or
A = (B+D)+(C+E)
or
A = (B+E)+(C+D)
or
A = (B+C)+(E+D)
or
...
No single set of rules can give the first created NaN because which
is first created is dependent on how the compiler ordered the FADDs.
> How can you
> use bits in the NaN value for debugging if the hardware is returning
arbitrary
> results when NaNs collide?
My 66000 has specific rules covering {Operand NaNs, Created NaNs}
which attempt to preserve the earliest created NaN and to properly
propagate Operand NaN values.
> Users have almost no control over whether
> A = B + C treats B as the first argument or the second.
Optimizers treat B and C as independent optimization opportunities.
> I think encoding stuff in NaN is a very 80's idea: turning on exceptions
> costs performance, so we want to debug after-the-fact using NaNs.
>
> But I think RISC-V has the right modern idea: make hardware fast so you can
> simply always enable Invalid Operation Traps (and maybe Overflow, if
> infinities are happening), and then stop right at the point of NaN being
> first created. So the NaN propagation doesn't matter.
This is a 1960s idea. Stop at the first occurrence of trouble. More
workable than NaNs, but has its own set of baggage--for example how
does one stop 13 elements into a Vector instruction ???
{{BTW: My 66000 has a way to scalarize vector code 13 elements into
the vector, and after the exception has been handled, to reenter
vector operation.}}
> I think the common current debug strategy for NaNs is run at full speed
> with exceptions masked, and if you get NaNs in your answer, you re-run
> with exceptions on and then debug the traps that occur. And no one looks at
> the NaN values at all, just their presence.
Yes, this is a common strategy, and with the list of architectures that
"all do it differently" what else could one expect.
> So rather than spending time on NaN encoding, make it so that FP performance
> is not affected by enabling exceptions, so we can skip the re-running step,
> and just run with Invalid Operations trapping enabled. And then just
> return canonical NaNs.
My 66000 has that option available.
>
> Kent
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
