From: gneuner2@comcast.net
On Sun, 23 Nov 2025 23:58:16 -0500, Robert Finch
wrote:
>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/
ackground/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.
This discussion reminds me somewhat of Ivan Godard's description of
NAR faults on the Mill. Because of wide issue, just having the
address of the offending instruction was not very helpful - you needed
to know which of the many operations within the instruction was the
culprit. And because NARs flow through speculated code, the offending
site could be hundreds of operations away by the time the fault is
signaled and pops out.
Ivan discusses NARs in the "metadata" talk. Around 1h:25m, he
describes the way Mill (approximately) encodes a fault location using
a hash code created from the address of the code block, the
instruction's issue cycle within the block, and the slot of the
operation that failed. They stick the LO bits of this hash into
however many bits are available for the payload. The NAR itself has a
type, and the payload width depends on the data type produced by the
faulting operation.
Obviously that all is Mill specific, but it may stimulate another,
better idea that is relevant to your design.
YMMV.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
