From: user5857@newsgrouper.org.invalid   
      
   Robert Finch  posted:   
      
   > On 2025-11-23 3:13 p.m., MitchAlsup wrote:   
   > >   
   > > Robert Finch  posted:   
   > >   
   > >> On 2025-11-22 10:20 p.m., MitchAlsup wrote:   
   > >>>   
   > >>> 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   
   background/nan-propagation.pdf   
   > >>> For conversation about LoBs versus HoBs.   
   > >>>   
   > >>   
   > >> Okay, it sounds like there are good reasons to use the HoBs. But I think   
   > >> it is only when converting precisions that it makes a difference. I have   
   > >> the float package moving the LoBs of a larger precision to the LoBs of   
   > >> the lower precision if a NaN (or infinity) is present. I do not think   
   > >> this consumes any more logic. It looks like just wires. It looks to be a   
   > >> three bit mux on the low order bits going the other way.   
   > >   
   > > The other part of the paper's reasoning is that if you want to insert   
   > > some portion of IP in NaN, doing it bit-reversed enables conversions   
   > > to smaller and larger to loose as few bits as possible. The realization   
   > > was a surprise to me (yesterday).   
   > >   
   >   
   > It is probably not possible to embed enough IP information in smaller   
   > floating-point formats (<=16-bit) to be worthwhile. For 32-bit floats   
   > only about 18-bits of the address can be stored. It looks like different   
   > formats are going to handle NaNs differently, which I find somewhat   
   > undesirable.   
   >   
   > I am now leaning towards allocating four HOB bits to indicate the NaN   
   > cause, and then  filling the rest of the payload with a bit reversed   
   > address. There should be some instruction to extract the NaN cause and   
   > address.   
   >   
   > I like the bit-reversed address idea. Losing high order address bits is   
   > less of an issue than low order ones.   
   >   
   >   The extra bit in the NaN cause may be used by software for when access   
   > to the payload area is desired for other purposes.   
   >   
   > I still like the idea of a NaN trace facility as an option. Perhaps the   
   > debugger logic could trigger a dump to trace on a NaN after a specific   
   > address.   
   >   
   > I think that just a cause code to indicate multiple NaNs colliding would   
   > be good. With the fused-dot-product there could be up to four NaNs. Some   
   > of the information is going to be lost, so might as well just assign a code.   
   >   
   > Insane idea: use more payload bits to record the colliding NaN causes,   
   > then dump it to a CSR somewhere when the address is inserted into the   
   > NaN. The FP status needs to be recorded, so maybe it could be part of   
   > that status record.   
   >   
   > My float package does not have access to an address, so it cannot be   
   > inserted in the individual modules where the NaN occurs. It must be   
   > inserted at a higher level in the FPU which I believe has access to the   
   > instruction address.   
   >   
   In this case, put the cause in a container the instruction drags down   
   the pipe, and retrieve it when you do have address access to where it   
   needs to go.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)