From: robfi680@gmail.com
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/b
ckground/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.
>> I suppose I could code the package to accept NaN values either way.
>>
>> The following NaN values are in use.
>>
>> `define QSUBINFD 63'h7FF0000000000001 // - infinity - infinity
>> `define QINFDIVD 63'h7FF0000000000002 // - infinity / infinity
>> `define QZEROZEROD 63'h7FF0000000000003 // - zero / zero
>> `define QINFZEROD 63'h7FF0000000000004 // - infinity X zero
>> `define QSQRTINFD 63'h7FF0000000000005 // - square root of infinity
>> `define QSQRTNEGD 63'h7FF0000000000006 // - square root of negaitve number
>>
>>
>>>>> 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)
|
