From: already5chosen@yahoo.com   
      
   On Thu, 27 Nov 2025 15:50:37 -0000 (UTC)   
   kegs@provalid.com (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   
      
   How do you ship your software to the end user? Are exceptions masked off   
   or enabled?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)