From: user5857@newsgrouper.org.invalid   
      
   Robert Finch  posted:   
      
   > On 2025-11-11 2:30 p.m., MitchAlsup wrote:   
   > >   
   > > Robert Finch  posted:   
   > >   
   > >> Typical process for NaN boxing is to set the high order bits of the   
   > >> value which causes the value to appear to be a NaN at higher precision.   
   > >   
   > > Any FP value representable in lower precision can be exactly represented   
   > > in higher precision.   
   > >   
   > >> I have been thinking about using some of the high order bits of the NaN   
   > >> (eg bits 32 to 51) to indicate the precision of the boxed value.   
   > >   
   > > When My 66000 generates a NaN it inserts the cause in the 3 HoBs and   
   > > inserts IP in the LoBs. Nothing prevents you from overwriting the NaN,   
   > > but I thought it was best to point at the causing-instruction and an   
   > > encoded "why" the nan was generated. The cause is a 3-bit index to the   
   > > 7 defined IEEE exceptions.   
   > >   
   > 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/backg   
   ound/nan-propagation.pdf   
   For conversation about LoBs versus HoBs.   
      
   > > There are rules when more than 1 NaN are an operand to an instruction   
   > > designed to leave the more important NaN as the result. {Where more   
   > > important is generally the first to be generated.}   
   > >   
   > Hopefully the package follows the rules correctly. NaN operation is one   
   > thing not tested yet.   
   >   
   > >>                                                                   This   
   > >> would allow detection of the use of a lower precision value in   
   > >> arithmetic. Suppose a convert from single to double precision is being   
   > >> done, but the value to be converted is only half precision. If it were   
   > >> indicated by the NaN software might be able to fix the result.   
   > >   
   > > I think it is better to fix the SW that thinks a (half) is a (float).   
   > >   
   > It would be better, but some software is so complex it may be unknown   
   > the values coming in. The SW does not really need to croak if its a   
   > lower precision value as they are always represent-able in a higher   
   > precision.>>   
   >      I also   
   > >> preserve the sign bit of the number in the NaN box.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)