Thinking of using the following for decimal floating-point:
|Sign 1| Exponent 9|Significand 70|
It is an 80-bit format so called extended double-precision.
Double precision is just barely adequate, extended double precision feels safer.
Groups of ten bits are needed to represent numbers in densely-packed-decimal format. 70 bits gives 21 significant digits.
The exponent is a power of ten represented as a binary number, so a nine-bit exponent has a good range (-255 to +256) considerably more than a binary exponent of the same size.
I have also been considering the following format which has 20 significant digits and a larger exponent, but packs digits in two different formats.
|Sign 1| Exponent 12|Lead digits 7|Significand 60|

The extended double format appeals to me because the hardware is quite a bit smaller than quad precision. I suppose I could use the quad precision format but only implement extended double precision in hardware. The least significant digits would be out to lunch and the exponent would not come close to full use.

robf...@gmail.com wrote:
> Thinking of using the following for decimal floating-point: |Sign 1|
> Exponent 9|Significand 70| It is an 80-bit format so called extended
> double-precision. Double precision is just barely adequate, extended
> double precision feels safer. Groups of ten bits are needed to
> represent numbers in densely-packed-decimal format. 70 bits gives 21
> significant digits. The exponent is a power of ten represented as a
> binary number, so a nine-bit exponent has a good range (-255 to +256)
> considerably more than a binary exponent of the same size. I have
> also been considering the following format which has 20 significant
> digits and a larger exponent, but packs digits in two different
> formats. |Sign 1| Exponent 12|Lead digits 7|Significand 60|
>
> The extended double format appeals to me because the hardware is
> quite a bit smaller than quad precision. I suppose I could use the
> quad precision format but only implement extended double precision in
> hardware. The least significant digits would be out to lunch and the
> exponent would not come close to full use.
>
What about having a hybrid, i.e. HW for the easy cases and fall back to
sw emulation for larger/higher precision inputs?

All this is presumably NOT speed critical, right?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 4/22/2022 2:52 AM, Terje Mathisen wrote:
> robf...@gmail.com wrote:
>> Thinking of using the following for decimal floating-point: |Sign 1|
>> Exponent 9|Significand 70| It is an 80-bit format so called extended
>> double-precision. Double precision is just barely adequate, extended
>> double precision feels safer. Groups of ten bits are needed to
>> represent numbers in densely-packed-decimal format. 70 bits gives 21
>> significant digits. The exponent is a power of ten represented as a
>> binary number, so a nine-bit exponent has a good range (-255 to +256)
>> considerably more than a binary exponent of the same size. I have
>> also been considering the following format which has 20 significant
>> digits and a larger exponent, but packs digits in two different
>> formats. |Sign 1| Exponent 12|Lead digits 7|Significand 60|
>>
>> The extended double format appeals to me because the hardware is
>> quite a bit smaller than quad precision. I suppose I could use the
>> quad precision format but only implement extended double precision in
>> hardware. The least significant digits would be out to lunch and the
>> exponent would not come close to full use.
>>
> What about having a hybrid, i.e. HW for the easy cases and fall back to
> sw emulation for larger/higher precision inputs?
>
> All this is presumably NOT speed critical, right?
>

I remain skeptical of the general-purpose viability of Decimal Floating
Point.

Binary FP is "already bad enough", and decimal FP is in nearly every way
worse, with the sole exceptions being:
Allows for slightly more efficient conversion to/from ASCII;
Can mimic controlled decimal rounding behavior...
But:
More complicated to deal with in hardware;
Will almost invariably be worse WRT cost and timing.

You don't just have an adder chain, now you got an adder chain trying to
fake doing decimal arithmetic.

One would have an FPU that is both more expensive and fundamentally more
expensive than a binary FPU.

....

However, these use-cases could be done better/cheaper via Packed BCD or
similar. Say, one treats a 64-bit number as 16 Packed BCD digits, with a
few special ops for ADD/SUB/CMP (*)/... with BCD numbers.
Also, with this approach one can use bit-shifts on decimal numbers.

*: For unsigned, one could use a normal integer compare. However, signed
integer and 10s complement would not cross over at the same point (well,
unless one is happy with it being asymmetric; then one can reuse signed
integer compare).

One would lose a few digits with Packed BCD vs DPD, but probably not a
huge loss.

Also, BCD seems to map up better with how decimal is handled in both
COBOL and SQL (eg: they will define the number of digits before and
after the decimal point), which is presumably where most of its use-case
would reside.

Well, oh well, in my case, I have an FPU:
Does Binary64 OK (FADD/FSUB/FMUL).
Had wanted a 96-bit format (128b in storage),
but, it makes FPU cost and timing more of an issue...
Recently added FDIV/FSQRT (sorta...).
... but its performance is basically a boat anchor ...

Generally, Binary32 and Binary16 see a lot more use than Binary96
probably would.

For many cases where Binary16 is used, one can also get away with a
cheaper "FDIV", namely approximating Rs/Rt with integer (Rs-Rt+Bias). I
am left to also wonder about the possibility of using a dynamic lookup
and LERPed bias, though in my testing it seems that getting the dynamic
bias be all that much more accurate than a constant bias is easier said
than done (probably still need to figure out which bits to use as
inputs; dynamic bias based on the high mantissa bits seems to work OK
with approximating a reciprocals/RCP, but falls short when it comes to DIV).

....

> Terje
>

BGB wrote:
> On 4/22/2022 2:52 AM, Terje Mathisen wrote:
>> robf...@gmail.com wrote:
>>> Thinking of using the following for decimal floating-point: |Sign 1|
>>> Exponent 9|Significand 70| It is an 80-bit format so called extended
>>> double-precision. Double precision is just barely adequate, extended
>>> double precision feels safer. Groups of ten bits are needed to
>>> represent numbers in densely-packed-decimal format. 70 bits gives 21
>>> significant digits. The exponent is a power of ten represented as a
>>> binary number, so a nine-bit exponent has a good range (-255 to +256)
>>> considerably more than a binary exponent of the same size. I have
>>> also been considering the following format which has 20 significant
>>> digits and a larger exponent, but packs digits in two different
>>> formats. |Sign 1| Exponent 12|Lead digits 7|Significand 60|
>>>
>>> The extended double format appeals to me because the hardware is
>>> quite a bit smaller than quad precision. I suppose I could use the
>>> quad precision format but only implement extended double precision in
>>> hardware. The least significant digits would be out to lunch and the
>>> exponent would not come close to full use.
>>>
>> What about having a hybrid, i.e. HW for the easy cases and fall back
>> to sw emulation for larger/higher precision inputs?
>>
>> All this is presumably NOT speed critical, right?
>>
>
> I remain skeptical of the general-purpose viability of Decimal Floating
> Point.

It is almost by definition NOT general-purpose.
>
>
> Binary FP is "already bad enough", and decimal FP is in nearly every way
> worse, with the sole exceptions being:
>   Allows for slightly more efficient conversion to/from ASCII;
>   Can mimic controlled decimal rounding behavior...
> But:
>   More complicated to deal with in hardware;
>   Will almost invariably be worse WRT cost and timing.
>
> You don't just have an adder chain, now you got an adder chain trying to
> fake doing decimal arithmetic.
>
> One would have an FPU that is both more expensive and fundamentally more
> expensive than a binary FPU.
>

Yeah.

It is fun though to figure out how to implement the binary-encoded
decimal option, this is where you end up having decimal scaling being
the only real problem/bottleneck, but you can do a lot using tables of
pre-calcuated reciprocals of powers of 5.

Michael S is the comp.arch resident guru of these things. :-)

> ...
>
>
> However, these use-cases could be done better/cheaper via Packed BCD or
> similar. Say, one treats a 64-bit number as 16 Packed BCD digits, with a
> few special ops for ADD/SUB/CMP (*)/... with BCD numbers.
> Also, with this approach one can use bit-shifts on decimal numbers.
>
> *: For unsigned, one could use a normal integer compare. However, signed
> integer and 10s complement would not cross over at the same point (well,
> unless one is happy with it being asymmetric; then one can reuse signed
> integer compare).
>
>
> One would lose a few digits with Packed BCD vs DPD, but probably not a
> huge loss.

AFAIK, all DPD-encoded decimal fp units starts operations by unpacking
the 10-bit chunks into 3 BCD digits.

That is at least the most obvious way to implement it, particularly
because the DPD encoding was chosen to allow very easy packing/unpacking
ops, cheap enough that you can easily have 10 of them in parallel.
>
> Also, BCD seems to map up better with how decimal is handled in both
> COBOL and SQL (eg: they will define the number of digits before and
> after the decimal point), which is presumably where most of its use-case
> would reside.

Right.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 4/22/2022 5:32 AM, Terje Mathisen wrote:
> BGB wrote:
>> On 4/22/2022 2:52 AM, Terje Mathisen wrote:
>>> robf...@gmail.com wrote:
>>>> Thinking of using the following for decimal floating-point: |Sign 1|
>>>> Exponent 9|Significand 70| It is an 80-bit format so called extended
>>>> double-precision. Double precision is just barely adequate, extended
>>>> double precision feels safer. Groups of ten bits are needed to
>>>> represent numbers in densely-packed-decimal format. 70 bits gives 21
>>>> significant digits. The exponent is a power of ten represented as a
>>>> binary number, so a nine-bit exponent has a good range (-255 to +256)
>>>> considerably more than a binary exponent of the same size. I have
>>>> also been considering the following format which has 20 significant
>>>> digits and a larger exponent, but packs digits in two different
>>>> formats. |Sign 1| Exponent 12|Lead digits 7|Significand 60|
>>>>
>>>> The extended double format appeals to me because the hardware is
>>>> quite a bit smaller than quad precision. I suppose I could use the
>>>> quad precision format but only implement extended double precision in
>>>> hardware. The least significant digits would be out to lunch and the
>>>> exponent would not come close to full use.
>>>>
>>> What about having a hybrid, i.e. HW for the easy cases and fall back
>>> to sw emulation for larger/higher precision inputs?
>>>
>>> All this is presumably NOT speed critical, right?
>>>
>>
>> I remain skeptical of the general-purpose viability of Decimal
>> Floating Point.
>
> It is almost by definition NOT general-purpose.
>>
>>
>> Binary FP is "already bad enough", and decimal FP is in nearly every
>> way worse, with the sole exceptions being:
>>    Allows for slightly more efficient conversion to/from ASCII;
>>    Can mimic controlled decimal rounding behavior...
>> But:
>>    More complicated to deal with in hardware;
>>    Will almost invariably be worse WRT cost and timing.
>>
>> You don't just have an adder chain, now you got an adder chain trying
>> to fake doing decimal arithmetic.
>>
>> One would have an FPU that is both more expensive and fundamentally
>> more expensive than a binary FPU.
>>
>
> Yeah.
>
> It is fun though to figure out how to implement the binary-encoded
> decimal option, this is where you end up having decimal scaling being
> the only real problem/bottleneck, but you can do a lot using tables of
> pre-calcuated reciprocals of powers of 5.
>
> Michael S is the comp.arch resident guru of these things. :-)
>

OK.

If one unpacks to BCD as an intermediate though, it becomes a
simpler/cheaper "shift by a multiple of 4 bits".

>> ...
>>
>>
>> However, these use-cases could be done better/cheaper via Packed BCD
>> or similar. Say, one treats a 64-bit number as 16 Packed BCD digits,
>> with a few special ops for ADD/SUB/CMP (*)/... with BCD numbers.
>> Also, with this approach one can use bit-shifts on decimal numbers.
>>
>> *: For unsigned, one could use a normal integer compare. However,
>> signed integer and 10s complement would not cross over at the same
>> point (well, unless one is happy with it being asymmetric; then one
>> can reuse signed integer compare).
>>
>>
>> One would lose a few digits with Packed BCD vs DPD, but probably not a
>> huge loss.
>
> AFAIK, all DPD-encoded decimal fp units starts operations by unpacking
> the 10-bit chunks into 3 BCD digits.
>
> That is at least the most obvious way to implement it, particularly
> because the DPD encoding was chosen to allow very easy packing/unpacking
> ops, cheap enough that you can easily have 10 of them in parallel.

This part is probably true at least. One could maybe have a converter op
that converts between 15 packed BCD digits, and DPD (50 bits).

If one excludes the combination field, this could almost match up with
the Decimal64 format. Could almost treat the last-digit (via the
combination field) as a special case.

Would almost make more sense though if the exponent and combination
field were in a different order, say:
Sgn.Exp8.Comb5.Fra50
In which case the converter op could be treated as:
15 digits in 50 bits.
16 digits in 55 bits.
Or, maybe also:
Sgn.Exp9.BCD1.Fra50

Which while losing 1 bit on the exponent range, is "less convoluted".

This could maybe make sense if one were implementing it mostly in
software using hardware Packed BCD and converter ops, which is probably
a cheaper option if compared with actually trying to do it directly in
hardware.

One could maybe skip the DPD part, and do a format like:
Sgn.Exp15.Fra112 (28 digit)
Or:
Sgn.Exp11.Fra116 (29 digit)
With the fraction as Packed BCD.

In this case, all one really needs to deal with effectively it in
software is some BCD helper ops.

I guess one could debate whether it would be better to go the route of
special ADD/SUB ops for BCD, or use the ALU as normal and then use a
"fixup ops".

Eg:
ADD R4, R5, R6 | CLRT //Clear SR.T
DAA R6 //Fixup BCD, treat SR.T as carry.
Or:
SUB R4, R5, R6 | CLRT //Clear SR.T
DAS R6 //Fixup BCD, treat SR.T as borrow.

This dedicated DAA/DAS route likely using less LUTs.

Dealing with 128-bits of BCD:
ADDX R4, R6, R8
CLRT
DAA R8
DAA R9

....

I could add these to BJX2, in theory, just not sure of a strong use-case
at the moment.

Less sure how multiply and divide would work, likely a pretty slow
option involving long multiply/divide, and another post fixup op likely
for dealing with multiplying a BCD number by a single BCD digit.

Could probably work, would be pretty slow, and would likely need "early
out" cases to deal with the rest of the digits being zeroes.

>>
>> Also, BCD seems to map up better with how decimal is handled in both
>> COBOL and SQL (eg: they will define the number of digits before and
>> after the decimal point), which is presumably where most of its
>> use-case would reside.
>
> Right.
>

Yeah, this is a thing:
Binary FP: Pretty much everywhere, lots of use-cases.
BCD: COBOL and SQL and similar.
Decimal FP: ?... ('finances' or something, *)

*: Except, here, you can't really auto-normalize (this would break the
rounding rules), so would only likely matter in "overflow" cases, but
these would likely break the rounding rules anyways (in the rare event
that a balance gets so big that it can no longer be contained).

One can argue, maybe an incorrectly rounded value is better than one
which overflows, but this is mostly sweeping the issue under the rug.

On Friday, April 22, 2022 at 2:19:24 PM UTC-4, BGB wrote:
> On 4/22/2022 5:32 AM, Terje Mathisen wrote:
> > BGB wrote:
> >> On 4/22/2022 2:52 AM, Terje Mathisen wrote:
> >>> robf...@gmail.com wrote:
> >>>> Thinking of using the following for decimal floating-point: |Sign 1|
> >>>> Exponent 9|Significand 70| It is an 80-bit format so called extended
> >>>> double-precision. Double precision is just barely adequate, extended
> >>>> double precision feels safer. Groups of ten bits are needed to
> >>>> represent numbers in densely-packed-decimal format. 70 bits gives 21
> >>>> significant digits. The exponent is a power of ten represented as a
> >>>> binary number, so a nine-bit exponent has a good range (-255 to +256)
> >>>> considerably more than a binary exponent of the same size. I have
> >>>> also been considering the following format which has 20 significant
> >>>> digits and a larger exponent, but packs digits in two different
> >>>> formats. |Sign 1| Exponent 12|Lead digits 7|Significand 60|
> >>>>
> >>>> The extended double format appeals to me because the hardware is
> >>>> quite a bit smaller than quad precision. I suppose I could use the
> >>>> quad precision format but only implement extended double precision in
> >>>> hardware. The least significant digits would be out to lunch and the
> >>>> exponent would not come close to full use.
> >>>>
> >>> What about having a hybrid, i.e. HW for the easy cases and fall back
> >>> to sw emulation for larger/higher precision inputs?
> >>>
> >>> All this is presumably NOT speed critical, right?
> >>>
> >>
> >> I remain skeptical of the general-purpose viability of Decimal
> >> Floating Point.
> >
> > It is almost by definition NOT general-purpose.
> >>
> >>
> >> Binary FP is "already bad enough", and decimal FP is in nearly every
> >> way worse, with the sole exceptions being:
> >> Allows for slightly more efficient conversion to/from ASCII;
> >> Can mimic controlled decimal rounding behavior...
> >> But:
> >> More complicated to deal with in hardware;
> >> Will almost invariably be worse WRT cost and timing.
> >>
> >> You don't just have an adder chain, now you got an adder chain trying
> >> to fake doing decimal arithmetic.
> >>
> >> One would have an FPU that is both more expensive and fundamentally
> >> more expensive than a binary FPU.
> >>
> >
> > Yeah.
> >
> > It is fun though to figure out how to implement the binary-encoded
> > decimal option, this is where you end up having decimal scaling being
> > the only real problem/bottleneck, but you can do a lot using tables of
> > pre-calcuated reciprocals of powers of 5.
> >
> > Michael S is the comp.arch resident guru of these things. :-)
> >
> OK.
>
> If one unpacks to BCD as an intermediate though, it becomes a
> simpler/cheaper "shift by a multiple of 4 bits".
> >> ...
> >>
> >>
> >> However, these use-cases could be done better/cheaper via Packed BCD
> >> or similar. Say, one treats a 64-bit number as 16 Packed BCD digits,
> >> with a few special ops for ADD/SUB/CMP (*)/... with BCD numbers.
> >> Also, with this approach one can use bit-shifts on decimal numbers.
> >>
> >> *: For unsigned, one could use a normal integer compare. However,
> >> signed integer and 10s complement would not cross over at the same
> >> point (well, unless one is happy with it being asymmetric; then one
> >> can reuse signed integer compare).
> >>
> >>
> >> One would lose a few digits with Packed BCD vs DPD, but probably not a
> >> huge loss.
> >
> > AFAIK, all DPD-encoded decimal fp units starts operations by unpacking
> > the 10-bit chunks into 3 BCD digits.
> >
> > That is at least the most obvious way to implement it, particularly
> > because the DPD encoding was chosen to allow very easy packing/unpacking
> > ops, cheap enough that you can easily have 10 of them in parallel.
> This part is probably true at least. One could maybe have a converter op
> that converts between 15 packed BCD digits, and DPD (50 bits).
>
> If one excludes the combination field, this could almost match up with
> the Decimal64 format. Could almost treat the last-digit (via the
> combination field) as a special case.
>
> Would almost make more sense though if the exponent and combination
> field were in a different order, say:
> Sgn.Exp8.Comb5.Fra50
> In which case the converter op could be treated as:
> 15 digits in 50 bits.
> 16 digits in 55 bits.
> Or, maybe also:
> Sgn.Exp9.BCD1.Fra50
>
> Which while losing 1 bit on the exponent range, is "less convoluted".
>
>
> This could maybe make sense if one were implementing it mostly in
> software using hardware Packed BCD and converter ops, which is probably
> a cheaper option if compared with actually trying to do it directly in
> hardware.
>
>
> One could maybe skip the DPD part, and do a format like:
> Sgn.Exp15.Fra112 (28 digit)
> Or:
> Sgn.Exp11.Fra116 (29 digit)
> With the fraction as Packed BCD.
>
>
> In this case, all one really needs to deal with effectively it in
> software is some BCD helper ops.
>
> I guess one could debate whether it would be better to go the route of
> special ADD/SUB ops for BCD, or use the ALU as normal and then use a
> "fixup ops".
>
> Eg:
> ADD R4, R5, R6 | CLRT //Clear SR.T
> DAA R6 //Fixup BCD, treat SR.T as carry.
> Or:
> SUB R4, R5, R6 | CLRT //Clear SR.T
> DAS R6 //Fixup BCD, treat SR.T as borrow.
>
> This dedicated DAA/DAS route likely using less LUTs.
>
>
> Dealing with 128-bits of BCD:
> ADDX R4, R6, R8
> CLRT
> DAA R8
> DAA R9
>
> ...
>
>
> I could add these to BJX2, in theory, just not sure of a strong use-case
> at the moment.
>
> Less sure how multiply and divide would work, likely a pretty slow
> option involving long multiply/divide, and another post fixup op likely
> for dealing with multiplying a BCD number by a single BCD digit.
>
> Could probably work, would be pretty slow, and would likely need "early
> out" cases to deal with the rest of the digits being zeroes.
> >>
> >> Also, BCD seems to map up better with how decimal is handled in both
> >> COBOL and SQL (eg: they will define the number of digits before and
> >> after the decimal point), which is presumably where most of its
> >> use-case would reside.
> >
> > Right.
> >
> Yeah, this is a thing:
> Binary FP: Pretty much everywhere, lots of use-cases.
> BCD: COBOL and SQL and similar.
> Decimal FP: ?... ('finances' or something, *)
>
>
> *: Except, here, you can't really auto-normalize (this would break the
> rounding rules), so would only likely matter in "overflow" cases, but
> these would likely break the rounding rules anyways (in the rare event
> that a balance gets so big that it can no longer be contained).
>
> One can argue, maybe an incorrectly rounded value is better than one
> which overflows, but this is mostly sweeping the issue under the rug.

> What about having a hybrid, i.e. HW for the easy cases and fall back
> to sw emulation for larger/higher precision inputs?

A hybrid approach is good. I was going to trap to software for things like
divide and square root. While having ADD, SUB, MUL, CMP in hardware.
Whether it is in hardware or software should be invisible to the program.

Performance is less critical than having decimal numbers to deal with. But
there can be quite a performance boost by having some of it processed in
hardware.

15 digits available with double precision may not be quite enough once one
uses several digits to maintain rounding. Using quad or even triple precision
is a bit ridiculous though. I happen to like the extended double, 80-bit,
format but there is no standard one for decimal floats AFAIK? An 82-bit format
like the Itanium is tempting, but a multiple of 8 or 16 bits is easier to work with.
I could probably live with a 72-bit format, giving 18 digits plus 11 bits exponent,
and one sign bit. But I think it is better to work with an even multiple of bytes.

On 4/22/2022 10:46 PM, robf...@gmail.com wrote:
> On Friday, April 22, 2022 at 2:19:24 PM UTC-4, BGB wrote:
>> On 4/22/2022 5:32 AM, Terje Mathisen wrote:
>>> BGB wrote:
>>>> On 4/22/2022 2:52 AM, Terje Mathisen wrote:
>>>>> robf...@gmail.com wrote:
>>>>>> Thinking of using the following for decimal floating-point: |Sign 1|
>>>>>> Exponent 9|Significand 70| It is an 80-bit format so called extended
>>>>>> double-precision. Double precision is just barely adequate, extended
>>>>>> double precision feels safer. Groups of ten bits are needed to
>>>>>> represent numbers in densely-packed-decimal format. 70 bits gives 21
>>>>>> significant digits. The exponent is a power of ten represented as a
>>>>>> binary number, so a nine-bit exponent has a good range (-255 to +256)
>>>>>> considerably more than a binary exponent of the same size. I have
>>>>>> also been considering the following format which has 20 significant
>>>>>> digits and a larger exponent, but packs digits in two different
>>>>>> formats. |Sign 1| Exponent 12|Lead digits 7|Significand 60|
>>>>>>
>>>>>> The extended double format appeals to me because the hardware is
>>>>>> quite a bit smaller than quad precision. I suppose I could use the
>>>>>> quad precision format but only implement extended double precision in
>>>>>> hardware. The least significant digits would be out to lunch and the
>>>>>> exponent would not come close to full use.
>>>>>>
>>>>> What about having a hybrid, i.e. HW for the easy cases and fall back
>>>>> to sw emulation for larger/higher precision inputs?
>>>>>
>>>>> All this is presumably NOT speed critical, right?
>>>>>
>>>>
>>>> I remain skeptical of the general-purpose viability of Decimal
>>>> Floating Point.
>>>
>>> It is almost by definition NOT general-purpose.
>>>>
>>>>
>>>> Binary FP is "already bad enough", and decimal FP is in nearly every
>>>> way worse, with the sole exceptions being:
>>>> Allows for slightly more efficient conversion to/from ASCII;
>>>> Can mimic controlled decimal rounding behavior...
>>>> But:
>>>> More complicated to deal with in hardware;
>>>> Will almost invariably be worse WRT cost and timing.
>>>>
>>>> You don't just have an adder chain, now you got an adder chain trying
>>>> to fake doing decimal arithmetic.
>>>>
>>>> One would have an FPU that is both more expensive and fundamentally
>>>> more expensive than a binary FPU.
>>>>
>>>
>>> Yeah.
>>>
>>> It is fun though to figure out how to implement the binary-encoded
>>> decimal option, this is where you end up having decimal scaling being
>>> the only real problem/bottleneck, but you can do a lot using tables of
>>> pre-calcuated reciprocals of powers of 5.
>>>
>>> Michael S is the comp.arch resident guru of these things. :-)
>>>
>> OK.
>>
>> If one unpacks to BCD as an intermediate though, it becomes a
>> simpler/cheaper "shift by a multiple of 4 bits".
>>>> ...
>>>>
>>>>
>>>> However, these use-cases could be done better/cheaper via Packed BCD
>>>> or similar. Say, one treats a 64-bit number as 16 Packed BCD digits,
>>>> with a few special ops for ADD/SUB/CMP (*)/... with BCD numbers.
>>>> Also, with this approach one can use bit-shifts on decimal numbers.
>>>>
>>>> *: For unsigned, one could use a normal integer compare. However,
>>>> signed integer and 10s complement would not cross over at the same
>>>> point (well, unless one is happy with it being asymmetric; then one
>>>> can reuse signed integer compare).
>>>>
>>>>
>>>> One would lose a few digits with Packed BCD vs DPD, but probably not a
>>>> huge loss.
>>>
>>> AFAIK, all DPD-encoded decimal fp units starts operations by unpacking
>>> the 10-bit chunks into 3 BCD digits.
>>>
>>> That is at least the most obvious way to implement it, particularly
>>> because the DPD encoding was chosen to allow very easy packing/unpacking
>>> ops, cheap enough that you can easily have 10 of them in parallel.
>> This part is probably true at least. One could maybe have a converter op
>> that converts between 15 packed BCD digits, and DPD (50 bits).
>>
>> If one excludes the combination field, this could almost match up with
>> the Decimal64 format. Could almost treat the last-digit (via the
>> combination field) as a special case.
>>
>> Would almost make more sense though if the exponent and combination
>> field were in a different order, say:
>> Sgn.Exp8.Comb5.Fra50
>> In which case the converter op could be treated as:
>> 15 digits in 50 bits.
>> 16 digits in 55 bits.
>> Or, maybe also:
>> Sgn.Exp9.BCD1.Fra50
>>
>> Which while losing 1 bit on the exponent range, is "less convoluted".
>>
>>
>> This could maybe make sense if one were implementing it mostly in
>> software using hardware Packed BCD and converter ops, which is probably
>> a cheaper option if compared with actually trying to do it directly in
>> hardware.
>>
>>
>> One could maybe skip the DPD part, and do a format like:
>> Sgn.Exp15.Fra112 (28 digit)
>> Or:
>> Sgn.Exp11.Fra116 (29 digit)
>> With the fraction as Packed BCD.
>>
>>
>> In this case, all one really needs to deal with effectively it in
>> software is some BCD helper ops.
>>
>> I guess one could debate whether it would be better to go the route of
>> special ADD/SUB ops for BCD, or use the ALU as normal and then use a
>> "fixup ops".
>>
>> Eg:
>> ADD R4, R5, R6 | CLRT //Clear SR.T
>> DAA R6 //Fixup BCD, treat SR.T as carry.
>> Or:
>> SUB R4, R5, R6 | CLRT //Clear SR.T
>> DAS R6 //Fixup BCD, treat SR.T as borrow.
>>
>> This dedicated DAA/DAS route likely using less LUTs.
>>
>>
>> Dealing with 128-bits of BCD:
>> ADDX R4, R6, R8
>> CLRT
>> DAA R8
>> DAA R9
>>
>> ...
>>
>>
>> I could add these to BJX2, in theory, just not sure of a strong use-case
>> at the moment.
>>
>> Less sure how multiply and divide would work, likely a pretty slow
>> option involving long multiply/divide, and another post fixup op likely
>> for dealing with multiplying a BCD number by a single BCD digit.
>>
>> Could probably work, would be pretty slow, and would likely need "early
>> out" cases to deal with the rest of the digits being zeroes.
>>>>
>>>> Also, BCD seems to map up better with how decimal is handled in both
>>>> COBOL and SQL (eg: they will define the number of digits before and
>>>> after the decimal point), which is presumably where most of its
>>>> use-case would reside.
>>>
>>> Right.
>>>
>> Yeah, this is a thing:
>> Binary FP: Pretty much everywhere, lots of use-cases.
>> BCD: COBOL and SQL and similar.
>> Decimal FP: ?... ('finances' or something, *)
>>
>>
>> *: Except, here, you can't really auto-normalize (this would break the
>> rounding rules), so would only likely matter in "overflow" cases, but
>> these would likely break the rounding rules anyways (in the rare event
>> that a balance gets so big that it can no longer be contained).
>>
>> One can argue, maybe an incorrectly rounded value is better than one
>> which overflows, but this is mostly sweeping the issue under the rug.
>
>> What about having a hybrid, i.e. HW for the easy cases and fall back
>> to sw emulation for larger/higher precision inputs?
>
> A hybrid approach is good. I was going to trap to software for things like
> divide and square root. While having ADD, SUB, MUL, CMP in hardware.
> Whether it is in hardware or software should be invisible to the program.
>
> Performance is less critical than having decimal numbers to deal with. But
> there can be quite a performance boost by having some of it processed in
> hardware.
>
> 15 digits available with double precision may not be quite enough once one
> uses several digits to maintain rounding. Using quad or even triple precision
> is a bit ridiculous though. I happen to like the extended double, 80-bit,
> format but there is no standard one for decimal floats AFAIK? An 82-bit format
> like the Itanium is tempting, but a multiple of 8 or 16 bits is easier to work with.
> I could probably live with a 72-bit format, giving 18 digits plus 11 bits exponent,
> and one sign bit. But I think it is better to work with an even multiple of bytes.
>
>

Ivan Godard <ivan@millcomputing.com> schrieb:

> A (the?) significant use for decimal is Numeric in DBMSs and COBOL.
> That's 33 digits IIRC. The COBOL committee spent quite a lot of time
> with the IFFF-754 committee (I was a IEEE member) before the last IEEE
> standard, to make sure that the IEEE decimal would be big enough for
> real uses in commerce: numbers like the world GDP expressed in
> Zimbabwean Dollars to the mil.

POWER has 16 digits with long DFP, 34 with DFP Extended (128 bits).

World GDP was around 80,934,771,028,340 (for 2017?) so 14 digits.
In 2009, before one of the re-valuations, a Zimbabwean Dollar
was 300,000,000,000,000 to the US dollar (according to Wikipedia),
15 digits. So... it would fit, but just about.

On Friday, April 22, 2022 at 2:59:33 AM UTC+3, robf...@gmail.com wrote:
> Thinking of using the following for decimal floating-point:
> |Sign 1| Exponent 9|Significand 70|
> It is an 80-bit format so called extended double-precision.
> Double precision is just barely adequate, extended double precision feels safer.
> Groups of ten bits are needed to represent numbers in densely-packed-decimal format. 70 bits gives 21 significant digits.
> The exponent is a power of ten represented as a binary number, so a nine-bit exponent has a good range (-255 to +256) considerably more than a binary exponent of the same size.
> I have also been considering the following format which has 20 significant digits and a larger exponent, but packs digits in two different formats.
> |Sign 1| Exponent 12|Lead digits 7|Significand 60|
>
> The extended double format appeals to me because the hardware is quite a bit smaller than quad precision. I suppose I could use the quad precision format but only implement extended double precision in hardware. The least significant digits would be out to lunch and the exponent would not come close to full use.

The sanest option is to implement nothing in HW.
Quad-precision DFP is easy to implement in software in way that is only small integer factor slower than IBM's hardware.
And double-precision DFP, while easy to be made quite a lot faster in HW, than in SW, does not look useful.

As to your idea of non-standard intermediate precision, I propose t forget about it as fast as you can.

According to Michael S <already5chosen@yahoo.com>:
>The sanest option is to implement nothing in HW.
>Quad-precision DFP is easy to implement in software in way that is only small integer factor slower than IBM's hardware.
>And double-precision DFP, while easy to be made quite a lot faster in HW, than in SW, does not look useful.

What he said. The only use for DFP is to get consistent decimal precision and rounding.

In my youth I had to implement bond yield and price functions, e.g., if you pay $97 for
a bond with a face value of $100, that pays 3% paid semiannually, and that matures
four years, six months, and 15 days from now, what is the effective yield to maturity?
(Answer: 3.73%)

The correct answer is not the one that is mathematically most precise,
it's the one that matches the answer that everyone else gets using a
360 day synthetic calendar and cent rounding. I did it on a 286 with
binary IEEE FP and it would have been a lot easier with decimal FP.
These calculations are important (imagine the amounts all multiplied
by a million) but there aren't all that many of them.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Saturday, April 23, 2022 at 9:20:47 PM UTC+3, John Levine wrote:
> According to Michael S <already...@yahoo.com>:
> >The sanest option is to implement nothing in HW.
> >Quad-precision DFP is easy to implement in software in way that is only small integer factor slower than IBM's hardware.
> >And double-precision DFP, while easy to be made quite a lot faster in HW, than in SW, does not look useful.
> What he said. The only use for DFP is to get consistent decimal precision and rounding.
>
> In my youth I had to implement bond yield and price functions, e.g., if you pay $97 for
> a bond with a face value of $100, that pays 3% paid semiannually, and that matures
> four years, six months, and 15 days from now, what is the effective yield to maturity?
> (Answer: 3.73%)
>

Let's see if I understand a formula used by "everybody else". In Matlab/Octave
x=10000
for k=1:9 x = round(x*1.015) end
yield = (x / 9700)^(1/4.5)
Or should 15 days play a role as well?

> The correct answer is not the one that is mathematically most precise,
> it's the one that matches the answer that everyone else gets using a
> 360 day synthetic calendar and cent rounding. I did it on a 286 with
> binary IEEE FP and it would have been a lot easier with decimal FP.

If I understood the formula correctly then I don't see how double-precision DFP
will help to get the same result.
Now, with quad-precision DFP you will probably get the same result, but only
because there were only 9 iterations and 9*3digts = 27 digits < 34 digits.
With 12 or more iterations you wouldn't be that lucky.

> These calculations are important (imagine the amounts all multiplied
> by a million) but there aren't all that many of them.
>

And anyway DFP is only a little more likely to match the rules than BFP.
The sane way is, of course, to change the rules toward radical simplification.
Nowadays, I'd say, just allow to do all intermediate calculations in octal-precision
BFP, with rounding to the nearest. Then round the outcome to whatever old rules
prescribe.

> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Michael S wrote:
> On Friday, April 22, 2022 at 2:59:33 AM UTC+3, robf...@gmail.com
> wrote:
>> Thinking of using the following for decimal floating-point: |Sign
>> 1| Exponent 9|Significand 70| It is an 80-bit format so called
>> extended double-precision. Double precision is just barely
>> adequate, extended double precision feels safer. Groups of ten bits
>> are needed to represent numbers in densely-packed-decimal format.
>> 70 bits gives 21 significant digits. The exponent is a power of ten
>> represented as a binary number, so a nine-bit exponent has a good
>> range (-255 to +256) considerably more than a binary exponent of
>> the same size. I have also been considering the following format
>> which has 20 significant digits and a larger exponent, but packs
>> digits in two different formats. |Sign 1| Exponent 12|Lead digits
>> 7|Significand 60|
>>
>> The extended double format appeals to me because the hardware is
>> quite a bit smaller than quad precision. I suppose I could use the
>> quad precision format but only implement extended double precision
>> in hardware. The least significant digits would be out to lunch and
>> the exponent would not come close to full use.
>
> The sanest option is to implement nothing in HW. Quad-precision DFP
> is easy to implement in software in way that is only small integer
> factor slower than IBM's hardware. And double-precision DFP, while
> easy to be made quite a lot faster in HW, than in SW, does not look
> useful.

This would be my own first choice as well, but I've always been much
more of a SW than HW guy. :-)
>
> As to your idea of non-standard intermediate precision, I propose t
> forget about it as fast as you can.
>
Yeah, probably best unless this is for something highly specific, not to
be deployed anywhere else.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 4/23/2022 7:08 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
>> A (the?) significant use for decimal is Numeric in DBMSs and COBOL.
>> That's 33 digits IIRC. The COBOL committee spent quite a lot of time
>> with the IFFF-754 committee (I was a IEEE member) before the last IEEE
>> standard, to make sure that the IEEE decimal would be big enough for
>> real uses in commerce: numbers like the world GDP expressed in
>> Zimbabwean Dollars to the mil.
>
> POWER has 16 digits with long DFP, 34 with DFP Extended (128 bits).
>
> World GDP was around 80,934,771,028,340 (for 2017?) so 14 digits.
> In 2009, before one of the re-valuations, a Zimbabwean Dollar
> was 300,000,000,000,000 to the US dollar (according to Wikipedia),
> 15 digits. So... it would fit, but just about.

I suspect there are reasons why the Decimal crowd was mostly going for
128-bit formats...

As for whether or not it makes much sense for a hardware FPU is more
debatable.

Even for something like DBMS or COBOL, probably only a small part of the
total time is likely to be spent on decimal arithmetic, and
traditionally DBMS's are mostly IO bound anyways, ...

There is another possibility:
3x 32-bit, each encoding 000000000..999999999 (as integer numbers);
Last 32-bit number holds sign and exponent.

IIRC, the MS decimal format worked something like this.
I suspect this was mostly because they were optimizing for a software
implementation.

I had also at one point considered possibly using something like this on
BJX2, before mostly deciding to stick with Binary128 floating-point
(software-only for now).

FWIW: Doing Binary128 in software is one of the major use-cases for the
128-bit 'ALUX' extension.

As an experiment, I have gone and added/defined a few BCD instructions
for BJX2.

Had originally tried adding DAA/DAS style ops, but then realized that
they would have a fatal flaw, namely an inability to add things like
9999+9999 and get the correct result, because the way they were
implemented on x86 would only work if adding 2 digits at a time
(otherwise, one would also need to generate and stash an extra 16
carry-bits somewhere).

Instead needed to switch over to dedicated BCDADC/BCDSBB instructions,
which effectively handle both parts at the same time (via their own
dedicated adder).

Internally, the BCDSBB is basically just BCDADC but with 9s complement
and the carry-bit inverted.

Was only adding the ADC/SBB variants, because I don't think these would
be used enough to justify ADD/SUB forms in practice, nor on spending 3R
encodings on this.

These instructions will also be "Lane 1 only".

So, for example, adding two 32-digit BCD numbers would look like:
MOV R4, R2
MOV R5, R3
CLRT
BCDADC R5, R2
BCDADC R6, R3

Hid initially tried direct chaining the adders here, but this blew out
timing pretty hard. I am now using carry-select, still fiddling with
timing (I don't yet have this able to pass timing).

Adding two 64-bit numbers is already high-latency, adding extra LUTs in
front of it doesn't really help on this front.

Seems to add a cost of around 1 kLUT, more than I would have hoped, ...

Because it updates SR.T, can't currently put it on the "MUL" path (this
path would give it another clock-cycle to work with; 1c throughput 3c
latency). I had put it on the ALU-1 path, which forces it to have the
same latency as 64-bit ADD/SUB (1c throughput, 2c latency).

Could be done, would require adding logic to allow the MUL path to
update SR.T (and/or add another dedicated status flag for this purpose,
such as an 'A' flag, which would also probably be better from a timing
POV, given how tied up SR.T is with everything else going on in the core).

As for whether this is viable, dunno...

Could maybe make more sense if it were more likely to be used more than
"hardly ever".

On 4/23/2022 12:35 PM, BGB wrote:
> On 4/23/2022 7:08 AM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>> A (the?) significant use for decimal is Numeric in DBMSs and COBOL.
>>> That's 33 digits IIRC. The COBOL committee spent quite a lot of time
>>> with the IFFF-754 committee (I was a IEEE member) before the last IEEE
>>> standard, to make sure that the IEEE decimal would be big enough for
>>> real uses in commerce: numbers like the world GDP expressed in
>>> Zimbabwean Dollars to the mil.
>>
>> POWER has 16 digits with long DFP, 34 with DFP Extended (128 bits).
>>
>> World GDP was around 80,934,771,028,340 (for 2017?) so 14 digits.
>> In 2009, before one of the re-valuations, a Zimbabwean Dollar
>> was 300,000,000,000,000 to the US dollar (according to Wikipedia),
>> 15 digits.  So... it would fit, but just about.
>
>
> I suspect there are reasons why the Decimal crowd was mostly going for
> 128-bit formats...
>
> As for whether or not it makes much sense for a hardware FPU is more
> debatable.
>
> Even for something like DBMS or COBOL, probably only a small part of the
> total time is likely to be spent on decimal arithmetic, and
> traditionally DBMS's are mostly IO bound anyways, ...

Commercial work is throughput oriented. When we were defining the IEEE
decimal revision we got some numbers from Oracle: IIRC, 40% of CPU
cycles were in decimal emulation routines. Terje - does that match your
memory?

On Saturday, April 23, 2022 at 2:50:34 PM UTC-5, Ivan Godard wrote:
> On 4/23/2022 12:35 PM, BGB wrote:
> > On 4/23/2022 7:08 AM, Thomas Koenig wrote:
> >> Ivan Godard <iv...@millcomputing.com> schrieb:
> >>
> >>> A (the?) significant use for decimal is Numeric in DBMSs and COBOL.
> >>> That's 33 digits IIRC. The COBOL committee spent quite a lot of time
> >>> with the IFFF-754 committee (I was a IEEE member) before the last IEEE
> >>> standard, to make sure that the IEEE decimal would be big enough for
> >>> real uses in commerce: numbers like the world GDP expressed in
> >>> Zimbabwean Dollars to the mil.
> >>
> >> POWER has 16 digits with long DFP, 34 with DFP Extended (128 bits).
> >>
> >> World GDP was around 80,934,771,028,340 (for 2017?) so 14 digits.
> >> In 2009, before one of the re-valuations, a Zimbabwean Dollar
> >> was 300,000,000,000,000 to the US dollar (according to Wikipedia),
> >> 15 digits. So... it would fit, but just about.
> >
> >
> > I suspect there are reasons why the Decimal crowd was mostly going for
> > 128-bit formats...
> >
> > As for whether or not it makes much sense for a hardware FPU is more
> > debatable.
> >
> > Even for something like DBMS or COBOL, probably only a small part of the
> > total time is likely to be spent on decimal arithmetic, and
> > traditionally DBMS's are mostly IO bound anyways, ...
<
> Commercial work is throughput oriented. When we were defining the IEEE
> decimal revision we got some numbers from Oracle: IIRC, 40% of CPU
> cycles were in decimal emulation routines. Terje - does that match your
> memory?
<
This 40% would vary massively if the base CPU had decimal instructions
(like IBM 360) versus if it had nothing (MIPS) versus if it had only a trifling
(x86).

On 4/23/2022 2:50 PM, Ivan Godard wrote:
> On 4/23/2022 12:35 PM, BGB wrote:
>> On 4/23/2022 7:08 AM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>
>>>> A (the?) significant use for decimal is Numeric in DBMSs and COBOL.
>>>> That's 33 digits IIRC. The COBOL committee spent quite a lot of time
>>>> with the IFFF-754 committee (I was a IEEE member) before the last IEEE
>>>> standard, to make sure that the IEEE decimal would be big enough for
>>>> real uses in commerce: numbers like the world GDP expressed in
>>>> Zimbabwean Dollars to the mil.
>>>
>>> POWER has 16 digits with long DFP, 34 with DFP Extended (128 bits).
>>>
>>> World GDP was around 80,934,771,028,340 (for 2017?) so 14 digits.
>>> In 2009, before one of the re-valuations, a Zimbabwean Dollar
>>> was 300,000,000,000,000 to the US dollar (according to Wikipedia),
>>> 15 digits.  So... it would fit, but just about.
>>
>>
>> I suspect there are reasons why the Decimal crowd was mostly going for
>> 128-bit formats...
>>
>> As for whether or not it makes much sense for a hardware FPU is more
>> debatable.
>>
>> Even for something like DBMS or COBOL, probably only a small part of
>> the total time is likely to be spent on decimal arithmetic, and
>> traditionally DBMS's are mostly IO bound anyways, ...
>
> Commercial work is throughput oriented. When we were defining the IEEE
> decimal revision we got some numbers from Oracle: IIRC, 40% of CPU
> cycles were in decimal emulation routines. Terje - does that match your
> memory?

I guess it could make sense then, but then one has to answer whether DFP
is the answer, or whether plain BCD would be good enough.

Though, this would imply though that these sorts of use-cases are no
longer primarily IO bound?...

BCD is at least cheaper to support in hardware than full-hardware DFP,
and would be "a lot closer" than also running code to deal with
individual decimal digits.

Admittedly though, I am still having some timing issues with my attempt
at adding BCD ops.

Basic logic is along the lines of, per-digit (A+B):
If doing SUB, do 9's complement on B (4b->4b remapping);
Do D=A+B+Ci (5b intermediate, should map to a CARRY4);
Run it though a 5b 'case' block, to map to 5b Digit+Carry.
The case block uses fewer LUTs than an "if(D>9)D=D+6;" or similar.

This is then ganged up in groups of 4 digits (daisy-chained), with each
group having versions for a carry-in of 0 and 1, and a carry-out bit.

For result, gather up carry bits, then select groups for the output
value (as in a normal integer adder).

However, latency seems to be a bit worse than in a normal integer adder.

To be more useful for implementing DFP, would likely also need
instructions doing the packing/unpacking for DPD<->BCD.

This packing/unpacking part should (probably) be a little easier.

....

I guess a related mystery would be if it could make sense to support BCD
types as a C language extension.

Say:
__bcd64 //64-bit, 16 digits
__bcd128 //128-bit, 32 digits

Printing them could almost be done by reusing the normal hexadecimal
printing, except that signed values would require special support to
print as, say, "-1" rather than "9999999999999999" or similar...

Simple case is to only natively define them here as unsigned types.

Less obvious how the casting should work.

Functionally, it would make more sense to treat them as part of the SIMD
tower rather than the main number tower.
This would mean:
__bcd128 v0;
__int128 v1;
v1=(__int128)((__m128)v0); //raw bit copy
v1=(__int128)v0; //likely a runtime call or similar.

....

It is likely that whether BCD support exists in C would be independent
of whether BCD instructions exist in the ISA (as with the other types,
if there is not an HW instruction for it, it will handle it by calling a
runtime function).

Doing "cost effective" conversion would probably be feeding digits, 2 at
a time, through lookup tables or similar.

On Saturday, April 23, 2022 at 10:50:34 PM UTC+3, Ivan Godard wrote:
> On 4/23/2022 12:35 PM, BGB wrote:
> > On 4/23/2022 7:08 AM, Thomas Koenig wrote:
> >> Ivan Godard <iv...@millcomputing.com> schrieb:
> >>
> >>> A (the?) significant use for decimal is Numeric in DBMSs and COBOL.
> >>> That's 33 digits IIRC. The COBOL committee spent quite a lot of time
> >>> with the IFFF-754 committee (I was a IEEE member) before the last IEEE
> >>> standard, to make sure that the IEEE decimal would be big enough for
> >>> real uses in commerce: numbers like the world GDP expressed in
> >>> Zimbabwean Dollars to the mil.
> >>
> >> POWER has 16 digits with long DFP, 34 with DFP Extended (128 bits).
> >>
> >> World GDP was around 80,934,771,028,340 (for 2017?) so 14 digits.
> >> In 2009, before one of the re-valuations, a Zimbabwean Dollar
> >> was 300,000,000,000,000 to the US dollar (according to Wikipedia),
> >> 15 digits. So... it would fit, but just about.
> >
> >
> > I suspect there are reasons why the Decimal crowd was mostly going for
> > 128-bit formats...
> >
> > As for whether or not it makes much sense for a hardware FPU is more
> > debatable.
> >
> > Even for something like DBMS or COBOL, probably only a small part of the
> > total time is likely to be spent on decimal arithmetic, and
> > traditionally DBMS's are mostly IO bound anyways, ...
> Commercial work is throughput oriented. When we were defining the IEEE
> decimal revision we got some numbers from Oracle: IIRC, 40% of CPU
> cycles were in decimal emulation routines. Terje - does that match your
> memory?

I wouldn't believe Oracle when they say that the sun rises in the east.

According to Michael S <already5chosen@yahoo.com>:
>> In my youth I had to implement bond yield and price functions, e.g., if you pay $97 for
>> a bond with a face value of $100, that pays 3% paid semiannually, and that matures
>> four years, six months, and 15 days from now, what is the effective yield to maturity?
>>
>
>Let's see if I understand a formula used by "everybody else". In Matlab/Octave
>x=10000
>for k=1:9 x = round(x*1.015) end
>yield = (x / 9700)^(1/4.5)
>Or should 15 days play a role as well?

You bought the bond at a discount, so the $3 difference from par is
amortized over the time from when you bought it to when it's redeemed,
as part of the yield. There's also the detail that bond interest is
paid in arrears, so you are getting a payment in half a month, but
11/12 of that interest belongs to the person you bought the bond from
and was included in the price you paid, so only 1/12 of that first
payment counts toward the yield.

The actual formula is quite complex and I don't know it off the top of
my head.

>And anyway DFP is only a little more likely to match the rules than BFP.

It's a lot more likely when the formula specifies penny rounding.

>The sane way is, of course, to change the rules toward radical simplification.

Indeed, but we're several centuries too late.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 4/23/2022 3:25 PM, MitchAlsup wrote:
> On Saturday, April 23, 2022 at 2:50:34 PM UTC-5, Ivan Godard wrote:
>> On 4/23/2022 12:35 PM, BGB wrote:
>>> On 4/23/2022 7:08 AM, Thomas Koenig wrote:
>>>> Ivan Godard <iv...@millcomputing.com> schrieb:
>>>>
>>>>> A (the?) significant use for decimal is Numeric in DBMSs and COBOL.
>>>>> That's 33 digits IIRC. The COBOL committee spent quite a lot of time
>>>>> with the IFFF-754 committee (I was a IEEE member) before the last IEEE
>>>>> standard, to make sure that the IEEE decimal would be big enough for
>>>>> real uses in commerce: numbers like the world GDP expressed in
>>>>> Zimbabwean Dollars to the mil.
>>>>
>>>> POWER has 16 digits with long DFP, 34 with DFP Extended (128 bits).
>>>>
>>>> World GDP was around 80,934,771,028,340 (for 2017?) so 14 digits.
>>>> In 2009, before one of the re-valuations, a Zimbabwean Dollar
>>>> was 300,000,000,000,000 to the US dollar (according to Wikipedia),
>>>> 15 digits. So... it would fit, but just about.
>>>
>>>
>>> I suspect there are reasons why the Decimal crowd was mostly going for
>>> 128-bit formats...
>>>
>>> As for whether or not it makes much sense for a hardware FPU is more
>>> debatable.
>>>
>>> Even for something like DBMS or COBOL, probably only a small part of the
>>> total time is likely to be spent on decimal arithmetic, and
>>> traditionally DBMS's are mostly IO bound anyways, ...
> <
>> Commercial work is throughput oriented. When we were defining the IEEE
>> decimal revision we got some numbers from Oracle: IIRC, 40% of CPU
>> cycles were in decimal emulation routines. Terje - does that match your
>> memory?
> <
> This 40% would vary massively if the base CPU had decimal instructions
> (like IBM 360) versus if it had nothing (MIPS) versus if it had only a trifling
> (x86).

With a number like this, I would assume it probably means that they are
doing all of the decimal stuff by working on it one-digit-at-a-time in C
or something...

But, yeah, the x86 BCD instructions are, in a way, so limited as to be
borderline useless.

If one has instructions which can ADD/SUB BCD 16 digits at a time or
similar, this should be at least a little more usable.

Nevermind if MUL/DIV, Int<->BCD conversion, ... would still be potential
bottlenecks.

Granted, if one had semi-fast conversion to/from binary integer types,
this would make MUL/DIV less of an issue, because then one could reuse
the (probably significantly faster) binary integer multiply and divide
operations.

Even if purely software, I suspect the converter route would still
likely be faster than doing decimal long-multiply and long-division.

....

>>The sane way is, of course, to change the rules toward
>>radical simplification.
> Indeed, but we're several centuries too late.

Not only that: it's far from obvious what that "radical simplification"
would look like. Look at what IEEE's binary floating point stipulates.
I think a lot of the complexity is inherent in the problem. It is true
that financial rounding rules have extra complexity due to the
combination of rules inherited from different markets/areas, but even
without it it's hard.

Stefan

On Saturday, April 23, 2022 at 5:38:08 PM UTC-5, Stefan Monnier wrote:
> >>The sane way is, of course, to change the rules toward
> >>radical simplification.
> > Indeed, but we're several centuries too late.
<
> Not only that: it's far from obvious what that "radical simplification"
> would look like. Look at what IEEE's binary floating point stipulates.
<
Binary FP rounding has the properties of "low bias" and "numeric stability*".
<
> I think a lot of the complexity is inherent in the problem. It is true
> that financial rounding rules have extra complexity due to the
> combination of rules inherited from different markets/areas, but even
> without it it's hard.
<
There is nothing anyone can do to prevent legislation from creating
bias in rounding and causing numeric instabilities applied to monetary
transactions. That is: Decimal rounding will always be subject to the
whims of legislation without any regards to "reasonable arithmetic".
>
>
> Stefan
<
(*) repeatability might be a better word than stability.

On Saturday, April 23, 2022 at 6:38:08 PM UTC-4, Stefan Monnier wrote:
> >>The sane way is, of course, to change the rules toward
> >>radical simplification.
> > Indeed, but we're several centuries too late.
> Not only that: it's far from obvious what that "radical simplification"
> would look like. Look at what IEEE's binary floating point stipulates.
> I think a lot of the complexity is inherent in the problem. It is true
> that financial rounding rules have extra complexity due to the
> combination of rules inherited from different markets/areas, but even
> without it it's hard.
>
>
> Stefan

Okay, I am going with quad precision for processing. I will need to use a simpler
core to implement in the FPGA, I had hoped to avoid the 128-bit busses. There
are probably not many if any use cases for decimal floating point less than
double precision. But the less than quad precision formats may be handy for
lowering data transfer requirements across wire. If there is a small value
decimal number like $100.52 it could be transferred as single precision or BCD.
There are two bits available in the instruction to specify precision.

00 = reserved, 01 = decimal float single, 10 = decimal float double, 11 = decimal float quad

Being able to convert between BCD and decimal float might be handy.

The ISA has BCD add, subtract and multiply. BCD add / subtract takes only three
clock cycles for a full machine width operation (16 digits). Digits are processed in
pairs. The carries from a digit pair are saved between clock cycles and added in the
next cycles.

I may look at trying to come up with decimal float accelerator instructions for a software
implementation. Packing and unpacking decimal float numbers into registers comes to
mind. Only 32 BCD digits will fit into a 128-bit register. To get all 34 decimal digits a
136-bit register is required. A multiply would require 272 register bits. Great idea, a
machine with 136-bit registers.

My current machine is 80-bit registers. Used in pairs that would be 160-bits. Could use
triplets of registers in a 64-bit machine. It would take five registers to hold a multiplier
product though. Starts to take a lot of registers and clock cycles to use a 64-bit machine
for software decimal float.

On Saturday, April 23, 2022 at 6:20:33 PM UTC-5, robf...@gmail.com wrote:
> On Saturday, April 23, 2022 at 6:38:08 PM UTC-4, Stefan Monnier wrote:
> > >>The sane way is, of course, to change the rules toward
> > >>radical simplification.
> > > Indeed, but we're several centuries too late.
> > Not only that: it's far from obvious what that "radical simplification"
> > would look like. Look at what IEEE's binary floating point stipulates.
> > I think a lot of the complexity is inherent in the problem. It is true
> > that financial rounding rules have extra complexity due to the
> > combination of rules inherited from different markets/areas, but even
> > without it it's hard.
> >
> >
> > Stefan
> Okay, I am going with quad precision for processing. I will need to use a simpler
> core to implement in the FPGA, I had hoped to avoid the 128-bit busses. There
> are probably not many if any use cases for decimal floating point less than
> double precision. But the less than quad precision formats may be handy for
> lowering data transfer requirements across wire. If there is a small value
> decimal number like $100.52 it could be transferred as single precision or BCD.
> There are two bits available in the instruction to specify precision.
>
> 00 = reserved, 01 = decimal float single, 10 = decimal float double, 11 = decimal float quad
>
> Being able to convert between BCD and decimal float might be handy.
<
My thought is that with 32-digit fixed point, you cover the 99%-ile of what applications
actually need. Especially if 32-digit addition/subtraction is 2-3-4 cycles, with multiply
at less than 20 cycles, and division at less than 50 cycles.
<
>
> The ISA has BCD add, subtract and multiply. BCD add / subtract takes only three
> clock cycles for a full machine width operation (16 digits). Digits are processed in
> pairs. The carries from a digit pair are saved between clock cycles and added in the
> next cycles.
<
A = Rbcd1 + Rbcd2
C = A + 0x666666666666666666666
Answer = A + (C & 0x1111111111111110)
<
Done with a 3-input adder it fits in 1 cycle. {Hint, you use a 2-input adder to binary
add Rs1 and Rs2--in parallel you add Rs1 + Rs1 + 0x6666666666666666--then you
only allow the decimal carry bit at digit locations to be added--+--This last trick can
be performed by implementing a carry select output mux on a digit by digit basis.}
>
> I may look at trying to come up with decimal float accelerator instructions for a software
> implementation. Packing and unpacking decimal float numbers into registers comes to
> mind. Only 32 BCD digits will fit into a 128-bit register. To get all 34 decimal digits a
> 136-bit register is required. A multiply would require 272 register bits. Great idea, a
> machine with 136-bit registers.
<
It only costs 2-gates of delay (and 6 gates per digit) to convert from DPD to BCD.
Here, every 10-binary bits gives you 3 decimal digits. 128-bits gives you 36 digits
and 8 bits to "do stuff" with (sign, decimal exponent,...)
<
Repacking back to DPD only takes 2 gates of delay (and IIRC 7 gates per digit.)
>
> My current machine is 80-bit registers.
<
sorry about that.
<
> Used in pairs that would be 160-bits. Could use
> triplets of registers in a 64-bit machine. It would take five registers to hold a multiplier
> product though. Starts to take a lot of registers and clock cycles to use a 64-bit machine
> for software decimal float.
<
If you look at the clock counts for the latest Z-series DFP--it seems possible that SW would
be competitive with the right primitives.

On 4/23/2022 5:09 PM, MitchAlsup wrote:
> On Saturday, April 23, 2022 at 6:20:33 PM UTC-5, robf...@gmail.com wrote:
>> On Saturday, April 23, 2022 at 6:38:08 PM UTC-4, Stefan Monnier wrote:
>>>>> The sane way is, of course, to change the rules toward
>>>>> radical simplification.
>>>> Indeed, but we're several centuries too late.
>>> Not only that: it's far from obvious what that "radical simplification"
>>> would look like. Look at what IEEE's binary floating point stipulates.
>>> I think a lot of the complexity is inherent in the problem. It is true
>>> that financial rounding rules have extra complexity due to the
>>> combination of rules inherited from different markets/areas, but even
>>> without it it's hard.
>>>
>>>
>>> Stefan
>> Okay, I am going with quad precision for processing. I will need to use a simpler
>> core to implement in the FPGA, I had hoped to avoid the 128-bit busses. There
>> are probably not many if any use cases for decimal floating point less than
>> double precision. But the less than quad precision formats may be handy for
>> lowering data transfer requirements across wire. If there is a small value
>> decimal number like $100.52 it could be transferred as single precision or BCD.
>> There are two bits available in the instruction to specify precision.
>>
>> 00 = reserved, 01 = decimal float single, 10 = decimal float double, 11 = decimal float quad
>>
>> Being able to convert between BCD and decimal float might be handy.
> <
> My thought is that with 32-digit fixed point, you cover the 99%-ile of what applications
> actually need. Especially if 32-digit addition/subtraction is 2-3-4 cycles, with multiply
> at less than 20 cycles, and division at less than 50 cycles.
> <
>>
>> The ISA has BCD add, subtract and multiply. BCD add / subtract takes only three
>> clock cycles for a full machine width operation (16 digits). Digits are processed in
>> pairs. The carries from a digit pair are saved between clock cycles and added in the
>> next cycles.
> <
> A = Rbcd1 + Rbcd2
> C = A + 0x666666666666666666666
> Answer = A + (C & 0x1111111111111110)
> <
> Done with a 3-input adder it fits in 1 cycle. {Hint, you use a 2-input adder to binary
> add Rs1 and Rs2--in parallel you add Rs1 + Rs1 + 0x6666666666666666--then you
> only allow the decimal carry bit at digit locations to be added--+--This last trick can
> be performed by implementing a carry select output mux on a digit by digit basis.}
>>
>> I may look at trying to come up with decimal float accelerator instructions for a software
>> implementation. Packing and unpacking decimal float numbers into registers comes to
>> mind. Only 32 BCD digits will fit into a 128-bit register. To get all 34 decimal digits a
>> 136-bit register is required. A multiply would require 272 register bits. Great idea, a
>> machine with 136-bit registers.
> <
> It only costs 2-gates of delay (and 6 gates per digit) to convert from DPD to BCD.
> Here, every 10-binary bits gives you 3 decimal digits. 128-bits gives you 36 digits
> and 8 bits to "do stuff" with (sign, decimal exponent,...)
> <
> Repacking back to DPD only takes 2 gates of delay (and IIRC 7 gates per digit.)
>>
>> My current machine is 80-bit registers.
> <
> sorry about that.
> <
>> Used in pairs that would be 160-bits. Could use
>> triplets of registers in a 64-bit machine. It would take five registers to hold a multiplier
>> product though. Starts to take a lot of registers and clock cycles to use a 64-bit machine
>> for software decimal float.
> <
> If you look at the clock counts for the latest Z-series DFP--it seems possible that SW would
> be competitive with the right primitives.

Software is easier if you define your own semantics :-) There's this
thing called "preferred quantum". Any multiply must rescale. You can't
just add a number in pennies to a number in dollars, and the
precision-conserving scaling you are used to from BFP is wrong.

Roughly speaking, BCD ops in hardware make implementing DFP easier/less
expensive, but you can't just convert DFP to BCD and add away willy-nilly.

On Saturday, April 23, 2022 at 7:37:40 PM UTC-5, Ivan Godard wrote:
> On 4/23/2022 5:09 PM, MitchAlsup wrote:
> > On Saturday, April 23, 2022 at 6:20:33 PM UTC-5, robf...@gmail.com wrote:
> >> On Saturday, April 23, 2022 at 6:38:08 PM UTC-4, Stefan Monnier wrote:
> >>>>> The sane way is, of course, to change the rules toward
> >>>>> radical simplification.
> >>>> Indeed, but we're several centuries too late.
> >>> Not only that: it's far from obvious what that "radical simplification"
> >>> would look like. Look at what IEEE's binary floating point stipulates.
> >>> I think a lot of the complexity is inherent in the problem. It is true
> >>> that financial rounding rules have extra complexity due to the
> >>> combination of rules inherited from different markets/areas, but even
> >>> without it it's hard.
> >>>
> >>>
> >>> Stefan
> >> Okay, I am going with quad precision for processing. I will need to use a simpler
> >> core to implement in the FPGA, I had hoped to avoid the 128-bit busses. There
> >> are probably not many if any use cases for decimal floating point less than
> >> double precision. But the less than quad precision formats may be handy for
> >> lowering data transfer requirements across wire. If there is a small value
> >> decimal number like $100.52 it could be transferred as single precision or BCD.
> >> There are two bits available in the instruction to specify precision.
> >>
> >> 00 = reserved, 01 = decimal float single, 10 = decimal float double, 11 = decimal float quad
> >>
> >> Being able to convert between BCD and decimal float might be handy.
> > <
> > My thought is that with 32-digit fixed point, you cover the 99%-ile of what applications
> > actually need. Especially if 32-digit addition/subtraction is 2-3-4 cycles, with multiply
> > at less than 20 cycles, and division at less than 50 cycles.
> > <
> >>
> >> The ISA has BCD add, subtract and multiply. BCD add / subtract takes only three
> >> clock cycles for a full machine width operation (16 digits). Digits are processed in
> >> pairs. The carries from a digit pair are saved between clock cycles and added in the
> >> next cycles.
> > <
> > A = Rbcd1 + Rbcd2
> > C = A + 0x666666666666666666666
> > Answer = A + (C & 0x1111111111111110)
> > <
> > Done with a 3-input adder it fits in 1 cycle. {Hint, you use a 2-input adder to binary
> > add Rs1 and Rs2--in parallel you add Rs1 + Rs1 + 0x6666666666666666--then you
> > only allow the decimal carry bit at digit locations to be added--+--This last trick can
> > be performed by implementing a carry select output mux on a digit by digit basis.}
> >>
> >> I may look at trying to come up with decimal float accelerator instructions for a software
> >> implementation. Packing and unpacking decimal float numbers into registers comes to
> >> mind. Only 32 BCD digits will fit into a 128-bit register. To get all 34 decimal digits a
> >> 136-bit register is required. A multiply would require 272 register bits. Great idea, a
> >> machine with 136-bit registers.
> > <
> > It only costs 2-gates of delay (and 6 gates per digit) to convert from DPD to BCD.
> > Here, every 10-binary bits gives you 3 decimal digits. 128-bits gives you 36 digits
> > and 8 bits to "do stuff" with (sign, decimal exponent,...)
> > <
> > Repacking back to DPD only takes 2 gates of delay (and IIRC 7 gates per digit.)
> >>
> >> My current machine is 80-bit registers.
> > <
> > sorry about that.
> > <
> >> Used in pairs that would be 160-bits. Could use
> >> triplets of registers in a 64-bit machine. It would take five registers to hold a multiplier
> >> product though. Starts to take a lot of registers and clock cycles to use a 64-bit machine
> >> for software decimal float.
> > <
> > If you look at the clock counts for the latest Z-series DFP--it seems possible that SW would
> > be competitive with the right primitives.
> Software is easier if you define your own semantics :-) There's this
> thing called "preferred quantum". Any multiply must rescale. You can't
> just add a number in pennies to a number in dollars, and the
> precision-conserving scaling you are used to from BFP is wrong.
>
> Roughly speaking, BCD ops in hardware make implementing DFP easier/less
> expensive, but you can't just convert DFP to BCD and add away willy-nilly.
<
I was not--I was leaving EVERYTHING in BCD/DPD and doing NOTHING in DFP.
<
It seems to me that when doing cash calculations; more than 99% of these
calculations stay within a single numeric system ($ = $ + $;...) and the very
vast majority need no extra digits behind the decimal point. After all the unit
quantum is (in the $ system) the penny ($0.01) so you don't buy 7.6 units
and the unit cost is not $x.yzabc unless abc=000.
<
Only the application of taxes requires more precision, and here, every state gets
to define the point of rounding and the methods of rounding.
<
Converting world GDP into the least valuable monetary system needs no more
precision than found in eXcel--precisely because the meaning of the calculated
value is without worth.
<
<---------------------------------------------------------------------------------------------------------------------------
<
But let us consider that DFP was easy to provide, and that MS was feeling
benign one day*, and put DFP into eXcel.
<
I put it to you that the surprise factor encountered in eXcel would not be
diminished.
<
(*) MS has never operated that benignly on any given day since about 1981.....