From: robfi680@gmail.com
On 2025-11-27 10:50 a.m., Kent Dickey wrote:
> 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. How can you
> use bits in the NaN value for debugging if the hardware is returning
arbitrary
> results when NaNs collide? Users have almost no control over whether
> A = B + C treats B as the first argument or the second.
>
> 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.
>
> 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.
>
> 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.
>
> Kent
I do not know how one would make FP performance improve and have
exceptions at the same time. The FP would have to operate asynchronous.
The only thing I can think of is to have core(s) specifically dedicated
to performance FP that do not service interrupts.
Given that nobody looks at the NaN values it is tempting to leave out
the NaN info, but I think I will still have it as an input to modules
where NaNs can be generated (when I get around to it). The NaN info can
always be set to zeros then and the extra logic should disappear then.
I think that there may be a reason why nobody looks at the NaN values.
IDK but maybe the debug does not make it easy to spot. A NaN display
with a random assortment of digits is pretty useless. But if debug where
to display all the address and other info, would it get used?
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
