From: cr88192@gmail.com
On 11/3/2025 9:22 AM, Scott Lurndal wrote:
> Terje Mathisen writes:
>> Michael S wrote:
>
>>> I mostly use ULP/Guard/Sticky in the same meaning. Except when I use
>>> them, esp. Guard, differently.
>>> Given the choice, [in the context of binary floating point] I'd rather
>>> not use the term 'guard' at all. Names like 'rounding bit' or
>>> 'half-ULP' are far more self-describing.
>>
>> Guard also works for decimal FP, where you need a single Sticky bit if
>> the Guard digit is equal to 5.
>
> By decimal FP, do you mean BCD? I.e. a format where
> you have a BCD exponent sign digit (BCD 'C' or 'D')
> followed by two BCD exponent digits, followed by a
> mantissa sign digit ('C' or 'D') followed by a variable
> number of mantissa digits (1 to 100)?
I would assume he meant something like either the newer IEEE-754 decimal
formats, or a decimal-FP format that MS had used in .NET, ...
The IEEE formats are generally one of:
Linear mantissa understood as decimal;
Groups of 10-bits, each used to encode 3 digits.
As Densely Packed Decimal.
With a power-of-10 exponent.
The .NET format was similar, except using groups of 32 bits as linear
values representing 9 digits.
When I looked at it before, the most practical way to me to support
something like this seemed to be to not do it directly in hardware, but
to support a subset of operations:
Operations to pack and unpack DPD into BCD;
Say: 64 bit value holds 15 BCD digits, mapped to 50 bits of DPD.
Some basic operations to help with arithmetic on BCD.
I partly implemented these as an experiment before, but then noted I
have basically no use case for Decimal-FP in my project.
And, ironically, the main benefit the helpers would have provided would
be to allow for faster Binary<->Decimal conversion. But, even then are
debatable, as Binary<->Decimal conversion isn't itself enough CPU time
to justify making it faster at the cost of needing to drag around BCD
helper instructions.
One downside is that there was no multiplier, so the BCD helpers would
need to be used to effectively implement a Radix-10 Shift-and-Add.
...
Though, it is debatable, something more like the .NET approach could
make more sense for a SW implementation.
If one wants to make the encoding more efficiently use the bits, a
hybrid approach could make sense, say:
Use 3 groups of 30 bits, and another group of 20 (6 digits)
Use an 17 bit linear exponent and sign bit.
This would be slightly cheaper to implement vs what is defined in the
standard (for the BID variant), and could achieve a similar effect
(though, with 33 digits rather than 34).
Internally, it could work similar to the .NET approach, just with a
little more up-front to pack/unpack the 30 bit components. The merit of
30 bit groups being that they map internally onto 32-bit integer
operations (which would also provide a space internally for carry/borrow
signaling in operations).
Most CPUs at least have native support for 32-bit integer math, and for
SW (on a 32/64 bit machine) this could be an easier chunking size than
10 bits. Someone could argue for 60 bit chunking on a 64-bit machine
(or, one 60 bit chunk, and a 50 bit chunk), but likely this wouldn't
save much over 30 bit chunking.
Also, 60-bit chunking would imply access to a 64*64->128 bit widening
multiply; which is asking more than 32*32->64. And, also precludes some
ways to more cheaply implement the divide/modulo step for each chunk
(*). So, it is likely in this sense 30 bit chunks could still be preferable.
*:
high=product>>30;
low=product-(high*1000000000LL);
if(low>=1000000000)
{ high++; low-=1000000000; }
Where, 60 bit chunking would require 128-bit math here.
Where, effectively, the multiply step is operating in radix-1-billion.
...
Still don't have much of a use-case though.
In general, Decimal-FP seems more like a solution in search of a problem.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
