Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

All constants are variables.


devel / comp.arch / Re: Extended double precision decimal floating point

SubjectAuthor
* Extended double precision decimal floating pointrobf...@gmail.com
+* Re: Extended double precision decimal floating pointTerje Mathisen
|`* Re: Extended double precision decimal floating pointBGB
| `* Re: Extended double precision decimal floating pointTerje Mathisen
|  `* Re: Extended double precision decimal floating pointBGB
|   `* Re: Extended double precision decimal floating pointrobf...@gmail.com
|    `* Re: Extended double precision decimal floating pointIvan Godard
|     `* Re: Extended double precision decimal floating pointThomas Koenig
|      `* Re: Extended double precision decimal floating pointBGB
|       +* Re: Extended double precision decimal floating pointIvan Godard
|       |+* Re: Extended double precision decimal floating pointMitchAlsup
|       ||`* Re: Extended double precision decimal floating pointBGB
|       || `* Re: Extended double precision decimal floating pointTerje Mathisen
|       ||  `- Re: Extended double precision decimal floating pointBGB
|       |+- Re: Extended double precision decimal floating pointBGB
|       |+- Re: Extended double precision decimal floating pointMichael S
|       |`* Re: Extended double precision decimal floating pointTerje Mathisen
|       | `* Re: Extended double precision decimal floating pointJohn Levine
|       |  `- Re: Extended double precision decimal floating pointIvan Godard
|       `- Re: Extended double precision decimal floating pointTerje Mathisen
`* Re: Extended double precision decimal floating pointMichael S
 +* Re: Extended double precision decimal floating pointJohn Levine
 |`* Re: Extended double precision decimal floating pointMichael S
 | `* Re: Extended double precision decimal floating pointJohn Levine
 |  +* Re: Extended double precision decimal floating pointStefan Monnier
 |  |+- Re: Extended double precision decimal floating pointMitchAlsup
 |  |`* Re: Extended double precision decimal floating pointrobf...@gmail.com
 |  | `* Re: Extended double precision decimal floating pointMitchAlsup
 |  |  +* Re: Extended double precision decimal floating pointIvan Godard
 |  |  |`- Re: Extended double precision decimal floating pointMitchAlsup
 |  |  +- Re: Extended double precision decimal floating pointBGB
 |  |  `* Re: Extended double precision decimal floating pointThomas Koenig
 |  |   `* Re: Extended double precision decimal floating pointMichael S
 |  |    +- Re: Extended double precision decimal floating pointTerje Mathisen
 |  |    `- Re: Extended double precision decimal floating pointThomas Koenig
 |  `* Re: Extended double precision decimal floating pointEricP
 |   `* Re: Financial arithmetic, was Extended double precision decimal floating pointJohn Levine
 |    `- Re: Financial arithmetic, was Extended double precision decimalTerje Mathisen
 +- Re: Extended double precision decimal floating pointTerje Mathisen
 `* Re: Extended double precision decimal floating pointQuadibloc
  `* Re: Extended double precision decimal floating pointBGB
   `* Re: Extended double precision decimal floating pointQuadibloc
    `* Re: Extended double precision decimal floating pointMitchAlsup
     +* Re: Extended double precision decimal floating pointIvan Godard
     |+* Re: Extended double precision decimal floating pointJohn Levine
     ||`- Re: Extended double precision decimal floating pointThomas Koenig
     |+* Re: Extended double precision decimal floating pointMitchAlsup
     ||`* Re: Extended double precision decimal floating pointIvan Godard
     || +* Re: Extended double precision decimal floating pointMichael S
     || |`- Re: Extended double precision decimal floating pointIvan Godard
     || `* Re: Extended double precision decimal floating pointMitchAlsup
     ||  `- Re: Extended double precision decimal floating pointIvan Godard
     |`* Re: Extended double precision decimal floating pointAnton Ertl
     | `* Re: Extended double precision decimal floating pointmac
     |  +- Re: Extended double precision decimal floating pointAnton Ertl
     |  `* Re: Extended double precision decimal floating pointQuadibloc
     |   `- Re: Extended double precision decimal floating pointQuadibloc
     +* Re: Extended double precision decimal floating pointQuadibloc
     |+- Re: Extended double precision decimal floating pointrobf...@gmail.com
     |+* Re: Extended double precision decimal floating pointAnton Ertl
     ||`* Re: IBM features, Extended double precision decimal floating pointJohn Levine
     || +* Re: IBM features, Extended double precision decimal floating pointJohn Dallman
     || |`- Re: IBM features, Extended double precision decimal floating pointQuadibloc
     || +* Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     || |+* Re: IBM features, Extended double precision decimal floating pointrobf...@gmail.com
     || ||+* Re: IBM features, Extended double precision decimal floating pointMitchAlsup
     || |||`- Re: IBM features, Extended double precision decimal floating pointJohn Levine
     || ||+- Re: IBM features, Extended double precision decimal floating pointBGB
     || ||`- Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     || |`* Re: IBM features, Extended double precision decimal floating pointJohn Levine
     || | `* Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     || |  +- Re: IBM features, Extended double precision decimal floating pointBGB
     || |  `* Re: IBM features, Extended double precision decimal floating pointJohn Levine
     || |   `- Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     || `* Re: IBM features, Extended double precision decimal floating pointAnton Ertl
     ||  `* Re: IBM features, Extended double precision decimal floating pointMitchAlsup
     ||   +* Re: IBM features, Extended double precision decimal floating pointAnton Ertl
     ||   |`- Re: IBM features, Extended double precision decimal floating pointThomas Koenig
     ||   `* Re: IBM features, Extended double precision decimal floating pointEricP
     ||    `- Re: IBM features, Extended double precision decimal floating pointEricP
     |+* Re: Extended double precision decimal floating pointIvan Godard
     ||+* Re: Extended double precision decimal floating pointMitchAlsup
     |||`* Re: Extended double precision decimal floating pointIvan Godard
     ||| +- Re: Extended double precision decimal floating pointMitchAlsup
     ||| `- Re: Extended double precision decimal floating pointQuadibloc
     ||`- Re: Extended double precision decimal floating pointThomas Koenig
     |`- Re: Extended double precision decimal floating pointMitchAlsup
     `* Re: Extended double precision decimal floating pointTerje Mathisen
      +* Re: Extended double precision decimal floating pointrobf...@gmail.com
      |+* Re: Extended double precision decimal floating pointIvan Godard
      ||`- Re: Extended double precision decimal floating pointMitchAlsup
      |+- Re: Extended double precision decimal floating pointTerje Mathisen
      |+- Re: Extended double precision decimal floating pointEricP
      |`- Re: Extended double precision decimal floating pointMitchAlsup
      +* Re: Extended double precision decimal floating pointMitchAlsup
      |`- Re: Extended double precision decimal floating pointBGB
      `* Re: Extended double precision decimal floating pointStefan Monnier
       `* Re: Extended double precision decimal floating pointTerje Mathisen
        `* Re: Extended double precision decimal floating pointStefan Monnier
         +* Re: Extended double precision decimal floating pointMitchAlsup
         |`* Re: Extended double precision decimal floating pointMichael S
         `* Re: Extended double precision decimal floating pointTerje Mathisen

Pages:12345
Re: Extended double precision decimal floating point

<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24856&group=comp.arch#24856

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:648:b0:2f3:642d:c12a with SMTP id a8-20020a05622a064800b002f3642dc12amr2256609qtb.464.1650782765148;
Sat, 23 Apr 2022 23:46:05 -0700 (PDT)
X-Received: by 2002:a05:6808:3012:b0:2ef:79c7:1342 with SMTP id
ay18-20020a056808301200b002ef79c71342mr327437oib.0.1650782764981; Sat, 23 Apr
2022 23:46:04 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 23 Apr 2022 23:46:04 -0700 (PDT)
In-Reply-To: <8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:5c04:dcd6:d35f:2f3e;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:5c04:dcd6:d35f:2f3e
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Sun, 24 Apr 2022 06:46:05 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 12
 by: Quadibloc - Sun, 24 Apr 2022 06:46 UTC

On Saturday, April 23, 2022 at 11:36:33 AM UTC-6, Michael S wrote:

> The sanest option is to implement nothing in HW.

While that may be true for an experimental floating-point format
that is not likely to see much use, in general that wouldn't be a
sane option, or even an option at all.

Because you will never get the fastest possible speed attainable
for floating-point operations unless you implement them in
dedicated hardware.

John Savard

Re: Extended double precision decimal floating point

<t42sb5$sia$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24857&group=comp.arch#24857

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 01:56:34 -0500
Organization: A noiseless patient Spider
Lines: 136
Message-ID: <t42sb5$sia$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<t41g1s$14hv$1@gal.iecc.com>
<d09babe7-ef1a-43f9-a619-f2adddf766e1n@googlegroups.com>
<t41p9p$24fj$1@gal.iecc.com> <jwvpml71ldb.fsf-monnier+comp.arch@gnu.org>
<78eacde9-f1d8-4ee4-b3d4-ec6c96b37157n@googlegroups.com>
<b8056fce-8bf6-4257-898b-25b9d23c16a4n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 24 Apr 2022 06:56:37 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="dc17ff8e6d4cf948036495052b0a97c2";
logging-data="29258"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18SDdOpTTz1T+cyxRrjlbVf"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:zuSME0BNSTGWX9mi3KIQMugTM7I=
In-Reply-To: <b8056fce-8bf6-4257-898b-25b9d23c16a4n@googlegroups.com>
Content-Language: en-US
 by: BGB - Sun, 24 Apr 2022 06:56 UTC

On 4/23/2022 7: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.
> <

2-cycle BCD ADD/SUB (for 16 digits) is doable...
This would do 32 digits in 3 cycles.

I eventually got my attempt to pass timing, turns out I needed to drop
the Carry-Select to operating on 2 digits at a time...

I had also switched it over to using the 'S' bit rather than the 'T'
bit, as the 'S' bit is slightly less "tied up" in other logic (timing
was easier). OTOH, consistency with "everything else" would assume using
the 'T' bit, but the result of trying to route lots of stuff through a
single bit, is that it turns this bit's logic path into an issue...

Eg:
2 digits per pair;
Select 2x 4 sets of carry values;
Select the full set of carry values based on the input Carry/Borrow bit;
Then, select bits for the final output.

I suspect that, in terms of latency, the 64b / 16-digit BCD adder is
maybe comparable to a 144 or 192 bit binary adder.

I have some doubts here about decimal multiply.

I can imagine it could be possible to use either long-multiply /
long-division (in decimal), or a hybrid approach (effectively using
binary shift-add multiply/divide with extra logic to "fix up" the
results into decimal, *).

*: This would be similar to the adder logic, but would need to deal with
a slightly larger input range and 2-bit carry. But, could potentially
work out cheaper than long multiply (in terms of resource cost), albeit
probably slower.

>>
>> 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 will need to test this, but (if this works) this would (almost) render
dedicated BCD ADD/SUB ops as "kinda moot".

>>
>> 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.)

Yeah.

I suspect this part shouldn't be too expensive (given it is effectively
bit-twiddly), but would need to test it.

>>
>> My current machine is 80-bit registers.
> <
> sorry about that.
> <

Yeah...
Funky register size seems like a probable source of endless pain.

In my case, I am still using 64 bit registers.

I get 128-bit via pairing, making use of the extra lanes for additional
register ports, allowing for moving more bits.

I suspect my approach works acceptably well.

>> 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.

Probably...

Re: Extended double precision decimal floating point

<t42vto$j6u$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24858&group=comp.arch#24858

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 07:57:44 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t42vto$j6u$1@newsreader4.netcologne.de>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<t41g1s$14hv$1@gal.iecc.com>
<d09babe7-ef1a-43f9-a619-f2adddf766e1n@googlegroups.com>
<t41p9p$24fj$1@gal.iecc.com> <jwvpml71ldb.fsf-monnier+comp.arch@gnu.org>
<78eacde9-f1d8-4ee4-b3d4-ec6c96b37157n@googlegroups.com>
<b8056fce-8bf6-4257-898b-25b9d23c16a4n@googlegroups.com>
Injection-Date: Sun, 24 Apr 2022 07:57:44 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd4:f179:0:7285:c2ff:fe6c:992d";
logging-data="19678"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sun, 24 Apr 2022 07:57 UTC

MitchAlsup <MitchAlsup@aol.com> schrieb:

> 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.

Where did you find them? It would be interesting to look at them.

For POWER9, I have the handbook before me. It gives 12 cycles
latency for daddq (quad add DFP), same as xsaddqp, the version
for a 128-bit IEEE floating point add.

How many cycles latency would you need for a IEEE qp add in
software?

Re: Extended double precision decimal floating point

<t431qo$g0m$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24859&group=comp.arch#24859

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 10:30:16 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t431qo$g0m$1@gioia.aioe.org>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<t3tmrd$m06$1@gioia.aioe.org> <t3trjp$t04$1@dont-email.me>
<t3u085$1165$1@gioia.aioe.org> <t3urj9$4ou$1@dont-email.me>
<aeef3da0-5f71-4cba-942e-0b99479e58f1n@googlegroups.com>
<t40o6j$oub$1@dont-email.me> <t40q7n$48b$1@newsreader4.netcologne.de>
<t41kdg$sgn$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="16406"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Sun, 24 Apr 2022 08:30 UTC

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

I used exactly this split when I wrote my own q&d 128-bit binary FP
library over a weekend in Jan 1995: I needed this to verify our sw FDIV
workaround code, including the FPATAN replacement.

Working with a mantissa having 3 32-bit values, with no subnormal or
hidden bit made most of the basic functions really easy to write. I
don't remember what I did for division but suspect I simply fell back on
subtract/compare, i.e. one bit per iteration since I for obvious reasons
could not use the HW FDIV ocpcode as a starting point. :-)

(I might have used integer 64/32->(32,32) as a building block,
multiplying back and subtracting but I don't remember.)

Having 64-bit unsigned regs and 64x64->128 make it far easier to get
reasonable speed from a sw implementation.

Terje

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

Re: Extended double precision decimal floating point

<t431u2$g0m$2@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24860&group=comp.arch#24860

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 10:32:01 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t431u2$g0m$2@gioia.aioe.org>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<t3tmrd$m06$1@gioia.aioe.org> <t3trjp$t04$1@dont-email.me>
<t3u085$1165$1@gioia.aioe.org> <t3urj9$4ou$1@dont-email.me>
<aeef3da0-5f71-4cba-942e-0b99479e58f1n@googlegroups.com>
<t40o6j$oub$1@dont-email.me> <t40q7n$48b$1@newsreader4.netcologne.de>
<t41kdg$sgn$1@dont-email.me> <t41la7$3hp$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="16406"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Sun, 24 Apr 2022 08:32 UTC

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?

Sorry, no, it never came up duing the 2016-2019 round afair.

I strongly doubt Oracle's numbers though: Spending 40% here seems like a
clear case of badly written SW.

Terje

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

Re: Extended double precision decimal floating point

<t432di$5l6$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24861&group=comp.arch#24861

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 03:40:15 -0500
Organization: A noiseless patient Spider
Lines: 26
Message-ID: <t432di$5l6$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 24 Apr 2022 08:40:18 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="dc17ff8e6d4cf948036495052b0a97c2";
logging-data="5798"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX191R305/uChV0VD0Fwc797m"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:fzOCAB8crCet5uIUrlfH3vpiax4=
In-Reply-To: <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
Content-Language: en-US
 by: BGB - Sun, 24 Apr 2022 08:40 UTC

On 4/24/2022 1:46 AM, Quadibloc wrote:
> On Saturday, April 23, 2022 at 11:36:33 AM UTC-6, Michael S wrote:
>
>> The sanest option is to implement nothing in HW.
>
> While that may be true for an experimental floating-point format
> that is not likely to see much use, in general that wouldn't be a
> sane option, or even an option at all.
>
> Because you will never get the fastest possible speed attainable
> for floating-point operations unless you implement them in
> dedicated hardware.
>

This is probably a lot more true of Binary FP than Decimal FP ...

If done poorly (or at the bare minimum) in hardware, it is also possible
for things to be slower than if they were done in software (software
having the ability to use special cases and much more clever algorithms
without blowing up the resource costs or putting a wrecking ball through
their timing constraints...).

> John Savard

Re: Extended double precision decimal floating point

<t4335e$10ip$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24862&group=comp.arch#24862

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 10:53:02 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t4335e$10ip$1@gioia.aioe.org>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<t3tmrd$m06$1@gioia.aioe.org> <t3trjp$t04$1@dont-email.me>
<t3u085$1165$1@gioia.aioe.org> <t3urj9$4ou$1@dont-email.me>
<aeef3da0-5f71-4cba-942e-0b99479e58f1n@googlegroups.com>
<t40o6j$oub$1@dont-email.me> <t40q7n$48b$1@newsreader4.netcologne.de>
<t41kdg$sgn$1@dont-email.me> <t41la7$3hp$1@dont-email.me>
<5d02036c-33d1-4881-b681-be99a64fcfden@googlegroups.com>
<t41pc9$2v7$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="33369"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Sun, 24 Apr 2022 08:53 UTC

BGB wrote:
> 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.

You have seen the algorithm I invented 20+ years ago to do really fast
conversion from binary to BCD or ASCII? Michael S have tweaked it a bit
more since then: You get the full 32-bit unsigned to 10 ASCII digits in
less than the time for a single DIV, while moving to 64-bit regs allows
you do do the same for 64-bit unsigned in maybe 50% more cycles.

Moving on to 128-bit DFP you have to split the mantissa into two or
three chunks first (div/mod 1e16 or 1e11), then you can convert these in
parallel.

BTW, it was Michael who suggested that you can do reciprocal
multiplication to emulate division by powers of ten for numbers that are
larger than 2^64, i.e. larger than 1e19: All the way up to 27 you can do
so by first extracting the powers of two with a simple SHRD, then you
divide by the corresponding factor of 5.

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

Re: Extended double precision decimal floating point

<477bdeb7-3324-4bf7-99c7-289948c74923n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24863&group=comp.arch#24863

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:44b4:0:b0:444:45d6:ec25 with SMTP id n20-20020ad444b4000000b0044445d6ec25mr9728788qvt.24.1650799250228;
Sun, 24 Apr 2022 04:20:50 -0700 (PDT)
X-Received: by 2002:a05:6808:181f:b0:322:3239:5539 with SMTP id
bh31-20020a056808181f00b0032232395539mr345290oib.1.1650799249998; Sun, 24 Apr
2022 04:20:49 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 24 Apr 2022 04:20:49 -0700 (PDT)
In-Reply-To: <t42vto$j6u$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=199.203.251.52; posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 199.203.251.52
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <t41g1s$14hv$1@gal.iecc.com>
<d09babe7-ef1a-43f9-a619-f2adddf766e1n@googlegroups.com> <t41p9p$24fj$1@gal.iecc.com>
<jwvpml71ldb.fsf-monnier+comp.arch@gnu.org> <78eacde9-f1d8-4ee4-b3d4-ec6c96b37157n@googlegroups.com>
<b8056fce-8bf6-4257-898b-25b9d23c16a4n@googlegroups.com> <t42vto$j6u$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <477bdeb7-3324-4bf7-99c7-289948c74923n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: already5...@yahoo.com (Michael S)
Injection-Date: Sun, 24 Apr 2022 11:20:50 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 40
 by: Michael S - Sun, 24 Apr 2022 11:20 UTC

On Sunday, April 24, 2022 at 10:57:48 AM UTC+3, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > 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.
> Where did you find them? It would be interesting to look at them.
>
> For POWER9, I have the handbook before me. It gives 12 cycles
> latency for daddq (quad add DFP), same as xsaddqp, the version
> for a 128-bit IEEE floating point add.
>
> How many cycles latency would you need for a IEEE qp add in
> software?

It would be very dependent on operands.
Cases that need no change of scale on either of operands will be very fast.
Those that have to multiply one of the inputs by power of 10 will be slower.
And those that have to re-normalize (==divide the mantissa of the sum by 10)
will be slowest.
If I understand DFP rules correctly, cancellation, as result of summation of operands with
opposite signs, is not the problem, since, unlike BFP, in this case we can leave the result
un-normalized.

I'd say, latency-wise easy cases could be as fast or a little faster than POWER9 HW.
Hard case will be 3-4 times slower.
Throghput is another matter. Typically, throughput of sw implementation will be only 2-2.5
times better than latency (well, on modern monster, like Apple M1, AMD Zen3 and Intel Golden
Cove, may be, 3 times better), so in this department POWER9 has huge advantage.
But I'd suspect that majority of DFP calculations is latency-bounded.

Also, I'd like to mention that IBM's DPD format is especially well-suited for addition and subtraction.
Less so, for multiplication.
So, for quad-precision multiplication, SW (operating on BID) wold be relatively closer to POWER9 HW.
POWER9 dmulq has latency of 18-84 clocks and throughput =1/7.
Software should be order of 25 to 100 in latency and, may be, 1/15 to 1/40 in throughput, but 1/40
shouldn't happen in real-world scenarios.

Now, my SW numbers are pulled out of thin air, but not out of vacuum, since, as mentioned above
by Terje, couple of years ago I did some work on the hardest part of the DFP multiplication algorithm.

Re: Extended double precision decimal floating point

<t43hac$rh4$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24864&group=comp.arch#24864

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 14:54:36 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t43hac$rh4$1@gioia.aioe.org>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<t41g1s$14hv$1@gal.iecc.com>
<d09babe7-ef1a-43f9-a619-f2adddf766e1n@googlegroups.com>
<t41p9p$24fj$1@gal.iecc.com> <jwvpml71ldb.fsf-monnier+comp.arch@gnu.org>
<78eacde9-f1d8-4ee4-b3d4-ec6c96b37157n@googlegroups.com>
<b8056fce-8bf6-4257-898b-25b9d23c16a4n@googlegroups.com>
<t42vto$j6u$1@newsreader4.netcologne.de>
<477bdeb7-3324-4bf7-99c7-289948c74923n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="28196"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Sun, 24 Apr 2022 12:54 UTC

Michael S wrote:
> On Sunday, April 24, 2022 at 10:57:48 AM UTC+3, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>>> 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.
>> Where did you find them? It would be interesting to look at them.
>>
>> For POWER9, I have the handbook before me. It gives 12 cycles
>> latency for daddq (quad add DFP), same as xsaddqp, the version
>> for a 128-bit IEEE floating point add.
>>
>> How many cycles latency would you need for a IEEE qp add in
>> software?
>
> It would be very dependent on operands.
> Cases that need no change of scale on either of operands will be very fast.
> Those that have to multiply one of the inputs by power of 10 will be slower.
> And those that have to re-normalize (==divide the mantissa of the sum by 10)
> will be slowest.
> If I understand DFP rules correctly, cancellation, as result of summation of operands with
> opposite signs, is not the problem, since, unlike BFP, in this case we can leave the result
> un-normalized.
>
> I'd say, latency-wise easy cases could be as fast or a little faster than POWER9 HW.
> Hard case will be 3-4 times slower.
> Throghput is another matter. Typically, throughput of sw implementation will be only 2-2.5
> times better than latency (well, on modern monster, like Apple M1, AMD Zen3 and Intel Golden
> Cove, may be, 3 times better), so in this department POWER9 has huge advantage.
> But I'd suspect that majority of DFP calculations is latency-bounded.
>
> Also, I'd like to mention that IBM's DPD format is especially well-suited for addition and subtraction.
> Less so, for multiplication.
> So, for quad-precision multiplication, SW (operating on BID) wold be relatively closer to POWER9 HW.
> POWER9 dmulq has latency of 18-84 clocks and throughput =1/7.
> Software should be order of 25 to 100 in latency and, may be, 1/15 to 1/40 in throughput, but 1/40
> shouldn't happen in real-world scenarios.
>
> Now, my SW numbers are pulled out of thin air, but not out of vacuum, since, as mentioned above
> by Terje, couple of years ago I did some work on the hardest part of the DFP multiplication algorithm.

I agree with pretty much all your estimates above, i.e. the common case
of DFPADD of equal-magnitude/exponent values could be done in ~10
cycles, matching the stated 12 for POWER9, but falling far behind when
having to rescale.

It would be reasonable to start with the assumption that the exponents
are equal and that the top digit of the mantissa is zero for both
numbers, i.e. no mixing of exponent and mantissa bits. This is just a
simple masked compare to verify suitability, then at the same time we
would have started a 113-bit ADD/ADC of the masked B mantissa into the
original A value to generate the answer which here cannot overflow.

This is the ~10 cycles base case, all other paths are significantly slower.

For DFPMUL I suspect that a binary mantissa is faster up to the point
where you have to rescale, this will unfortunately be very common.

Terje

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

Re: Extended double precision decimal floating point

<t43ies$vk7$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24865&group=comp.arch#24865

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 13:14:04 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t43ies$vk7$1@newsreader4.netcologne.de>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<t41g1s$14hv$1@gal.iecc.com>
<d09babe7-ef1a-43f9-a619-f2adddf766e1n@googlegroups.com>
<t41p9p$24fj$1@gal.iecc.com> <jwvpml71ldb.fsf-monnier+comp.arch@gnu.org>
<78eacde9-f1d8-4ee4-b3d4-ec6c96b37157n@googlegroups.com>
<b8056fce-8bf6-4257-898b-25b9d23c16a4n@googlegroups.com>
<t42vto$j6u$1@newsreader4.netcologne.de>
<477bdeb7-3324-4bf7-99c7-289948c74923n@googlegroups.com>
Injection-Date: Sun, 24 Apr 2022 13:14:04 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-f179-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd4:f179:0:7285:c2ff:fe6c:992d";
logging-data="32391"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sun, 24 Apr 2022 13:14 UTC

Michael S <already5chosen@yahoo.com> schrieb:
> On Sunday, April 24, 2022 at 10:57:48 AM UTC+3, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>> > 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.
>> Where did you find them? It would be interesting to look at them.
>>
>> For POWER9, I have the handbook before me. It gives 12 cycles
>> latency for daddq (quad add DFP), same as xsaddqp, the version
>> for a 128-bit IEEE floating point add.
>>
>> How many cycles latency would you need for a IEEE qp add in
>> software?
>
> It would be very dependent on operands.
> Cases that need no change of scale on either of operands will be very fast.
> Those that have to multiply one of the inputs by power of 10 will be slower.
> And those that have to re-normalize (==divide the mantissa of the sum by 10)
> will be slowest.
> If I understand DFP rules correctly, cancellation, as result of summation of operands with
> opposite signs, is not the problem, since, unlike BFP, in this case we can leave the result
> un-normalized.
>
> I'd say, latency-wise easy cases could be as fast or a little faster than POWER9 HW.
> Hard case will be 3-4 times slower.
> Throghput is another matter. Typically, throughput of sw implementation will be only 2-2.5
> times better than latency (well, on modern monster, like Apple M1, AMD Zen3 and Intel Golden
> Cove, may be, 3 times better), so in this department POWER9 has huge advantage.
> But I'd suspect that majority of DFP calculations is latency-bounded.
>
> Also, I'd like to mention that IBM's DPD format is especially well-suited for addition and subtraction.
> Less so, for multiplication.

> So, for quad-precision multiplication, SW (operating on BID) wold be relatively closer to POWER9 HW.
> POWER9 dmulq has latency of 18-84 clocks and throughput =1/7.

.... and it dispatches as a vector op (takes up two slices of a
superslice), so it certainly is heavyweight.

Interestingly enough, xsmulqp has a fixed 24 cycles of latency, but
a lower thgoughput of 1/13 and blocks the pipe for 12 cycles (same
as xsmaddqp, their QP FMA instructions, which is not surprising).

Decimal float being optimized for throughput makes sense, IMHO.

Re: Extended double precision decimal floating point

<n5f9K.5186$Awz.240@fx03.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24866&group=comp.arch#24866

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!peer01.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx03.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <t41g1s$14hv$1@gal.iecc.com> <d09babe7-ef1a-43f9-a619-f2adddf766e1n@googlegroups.com> <t41p9p$24fj$1@gal.iecc.com>
In-Reply-To: <t41p9p$24fj$1@gal.iecc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 72
Message-ID: <n5f9K.5186$Awz.240@fx03.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Sun, 24 Apr 2022 16:41:55 UTC
Date: Sun, 24 Apr 2022 12:41:22 -0400
X-Received-Bytes: 4415
 by: EricP - Sun, 24 Apr 2022 16:41 UTC

John Levine wrote:
> 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.

I built a bond pricing server and system 25 years ago for a customer.
It would listen to the price ticker and reprice the bond securities
database in real time and broadcast the price changes to a front end.
Written in C on (IIRC) a Pentium II with 64 MB running WinNT,
it could reprice the 25,000 bonds database under a second and
replaced a system which took over an hour to do the same.

The above is called a zero coupon discount bond and is just one of at
least 12 different kinds of standard bonds, some with multiple variants.
There are two formula for each, price given yield and yield given price.
There are also at least 5 different ways of counting dates.
Also there are analytic calculations that tell you things
like how fast the money is paid back (basically the
first and second derivative of each price calculation).

The extra 15 days is called the accrued interest and
as John said yes it matters, and for that kind of bond
is incorporated into the power the yield is raised to.
(I had to look that up in the book - I didn't remember it either.)

So it requires some kind of BFP or DFP POW(value,power) function,
the integer loop approach won't do.
It helps that most calculations can be separated into
the scaling part and the money part.

I found that binary double precision was fine for all bond calculations of
a single bonds' price or yield, the standards for which require 3 or more
digits before the decimal point and minimum of 8 below the decimal point,
with the final results truncated to 3 digits after the decimal.

More complex bonds are a geometric power series of multiple payments.
Calculating price from yield can use a loop for the individual payments,
though replacing it with a geometric power identity is faster,
but calculating yield from price is best done with a Newton-Raphson.
And again all using floating point POW/LOG/EXP functions.

>> 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.

Also those kinds of customers don't always react well to
suggestions on how changing their multi-billion dollar business
could make your project less complicated.

Re: Financial arithmetic, was Extended double precision decimal floating point

<t440ff$1q2e$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24867&group=comp.arch#24867

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: Financial arithmetic, was Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 17:13:19 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t440ff$1q2e$1@gal.iecc.com>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <d09babe7-ef1a-43f9-a619-f2adddf766e1n@googlegroups.com> <t41p9p$24fj$1@gal.iecc.com> <n5f9K.5186$Awz.240@fx03.iad>
Injection-Date: Sun, 24 Apr 2022 17:13:19 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="59470"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <d09babe7-ef1a-43f9-a619-f2adddf766e1n@googlegroups.com> <t41p9p$24fj$1@gal.iecc.com> <n5f9K.5186$Awz.240@fx03.iad>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Sun, 24 Apr 2022 17:13 UTC

According to EricP <ThatWouldBeTelling@thevillage.com>:
>John Levine wrote:
>> 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 above is called a zero coupon discount bond and is just one of at
>least 12 different kinds of standard bonds, some with multiple variants.

Actually, that's how you price any bond in the secondary market. If
the current market rate is different from the coupon rate on the bond,
which it usually is, the price of the bond goes up or down
correspondingly. The same formula should work for a zero by setting
the coupon rate to zero.

I agree that there are a lot of different formulas, and I was also able
to get reasonable performance using binary IEEE FP and careful rounding.
I did this in about 1985 so the details are a little foggy now.

>> Indeed, but we're several centuries too late.
>
>Also those kinds of customers don't always react well to
>suggestions on how changing their multi-billion dollar business
>could make your project less complicated.

The correct answer was definitely the answer that matched the ones
the bond guys were already using.

--
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

Re: Extended double precision decimal floating point

<t441u9$1uef$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24868&group=comp.arch#24868

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 17:38:17 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t441u9$1uef$1@gal.iecc.com>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <t41kdg$sgn$1@dont-email.me> <t41la7$3hp$1@dont-email.me> <t431u2$g0m$2@gioia.aioe.org>
Injection-Date: Sun, 24 Apr 2022 17:38:17 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="63951"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <t41kdg$sgn$1@dont-email.me> <t41la7$3hp$1@dont-email.me> <t431u2$g0m$2@gioia.aioe.org>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Sun, 24 Apr 2022 17:38 UTC

According to Terje Mathisen <terje.mathisen@tmsw.no>:
>Sorry, no, it never came up duing the 2016-2019 round afair.
>
>I strongly doubt Oracle's numbers though: Spending 40% here seems like a
>clear case of badly written SW.

Either that or the rest of the work was so trivial that the decimal emulation
was all that was left.

--
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

Re: Extended double precision decimal floating point

<t4442l$6ua$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24869&group=comp.arch#24869

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 13:14:41 -0500
Organization: A noiseless patient Spider
Lines: 281
Message-ID: <t4442l$6ua$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<t3tmrd$m06$1@gioia.aioe.org> <t3trjp$t04$1@dont-email.me>
<t3u085$1165$1@gioia.aioe.org> <t3urj9$4ou$1@dont-email.me>
<aeef3da0-5f71-4cba-942e-0b99479e58f1n@googlegroups.com>
<t40o6j$oub$1@dont-email.me> <t40q7n$48b$1@newsreader4.netcologne.de>
<t41kdg$sgn$1@dont-email.me> <t41la7$3hp$1@dont-email.me>
<5d02036c-33d1-4881-b681-be99a64fcfden@googlegroups.com>
<t41pc9$2v7$1@dont-email.me> <t4335e$10ip$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 24 Apr 2022 18:14:45 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="dc17ff8e6d4cf948036495052b0a97c2";
logging-data="7114"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+RCq5OTc8AXToryZWdQIDJ"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:60D50eRL3BWc/AO/7ygd/4awa74=
In-Reply-To: <t4335e$10ip$1@gioia.aioe.org>
Content-Language: en-US
 by: BGB - Sun, 24 Apr 2022 18:14 UTC

On 4/24/2022 3:53 AM, Terje Mathisen wrote:
> BGB wrote:
>> 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.
>
> You have seen the algorithm I invented 20+ years ago to do really fast
> conversion from binary to BCD or ASCII? Michael S have tweaked it a bit
> more since then: You get the full 32-bit unsigned to 10 ASCII digits in
> less than the time for a single DIV, while moving to 64-bit regs allows
> you do do the same for 64-bit unsigned in maybe 50% more cycles.
>

There are several algorithms I am aware of.
I am not sure if I know which one you have in mind.

Binary to Decimal can be done via multiplying by a fixed point value
which "squeezes" groups of one or more digits above the decimal point.

This approach is a little fiddly though (if not scaled or biased
correctly, it will generate garbage output).

So, say, for a pre-scaled value in R4:
MOV 0x028F5C28, R16 // (1<<32)/100
MOV 0x00000063, R17 // magic bias (99)
//above can be reused for multiple iterations
DMULU.L R4, R16, R18 //move digits above decimal point.
ADD R17, R18 //add bias
SHLD.Q R18, -32, R2 //get top 2 digits (2 digit output)
EXTU.L R18, R4 //discard bits above point (for next step)

The value needs to be prescaled to the correct range (and pre-biased),
which is another fixed-point multiply.

In particular, say, the full value range needs to map to the 32-bit unit
range: ~ (2^32)/1000000000, but this is not an integer multiple (so
would be another fixed point multiply, bias, and shift).

Getting from values in the 00..99 range to BCD could be done with a
lookup table.

The process could be partially unrolled if done as an ASM blob.

Could do the conversion to/from BCD between 2 and 4 digits at a time,
would mostly effect the size of the lookup tables, eg:
2-digit: ~ 154B + 100B
3-digit: ~ 3K + 1K
4-digit: ~ 40K + 10K

Not really sure if there is a faster approach.

There is also the more traditional algorithm (for binary to decimal), of
divide and modulo by powers of 10, but as noted, this is slower.

The traditional approach is more stable though, and does not need bias
and prescale steps in order to work.

BCD to binary would be a lookup table followed by multiply-and-add.

> Moving on to 128-bit DFP you have to split the mantissa into two or
> three chunks first (div/mod 1e16 or 1e11), then you can convert these in
> parallel.
>

Possibly.

My thinking is that one would likely need to split them into groups of 9
digits.

I guess parallel conversion could work, in my case one would just need
to take care as DMULU.L is a Lane-1 instruction.

> BTW, it was Michael who suggested that you can do reciprocal
> multiplication to emulate division by powers of ten for numbers that are
> larger than 2^64, i.e. larger than 1e19: All the way up to 27 you can do
> so by first extracting the powers of two with a simple SHRD, then you
> divide by the corresponding factor of 5.
>

Probably depends on ISA.

On BJX2, would make sense to stick with 32-bit units for this part, as
currently my options are:
DMULU.L // ~ 3 cycle (32*32->64)
DMULU.Q // 67 cycle (64*64->128)

Though, the later can also be done in software (via decomposing the
value and using DMULU.L ops). In my tasting, it is roughly break-even,
but this seems to be mostly due to function-call related overheads (less
of an issue for a specialized ASM blob). In bare ASM, doing it via
32-bit multiplies is faster.

The cost in this case is more indirect, as the cost is less with the
called function, and more the impacts that performing a function call
has on the generated code in the caller (which is apparently enough to
"eat the delta" in this case).

For divide, the hardware shift-add unit generally beats out the software
shift-subtract loops, but more specialized options (such as
multiply-by-reciprocal) are faster than the DIV instructions.

For integer divide by constant, my compiler will typically turn it into
a multiply-by-reciprocal.

As for splitting up or combining a 64-bit or 128-bit number most
efficiently into groups of 9 digits or similar, dunno...

I mostly think doing DIV/MOD by going through binary could be faster, as
by my current estimate, doing 16 or 32 digit long-multiply and
long-divide is likely to be "particularly slow".

Also note that BCD types in BGBCC would likely be (primarily)
runtime-call based.

I had started adding stuff for them, treating them mostly as subset of
the SIMD vector types.

Where, type-tower:
SmallInt128:
int128, uint128
SmallLong:
int64(long), uint64(ulong)
SmallInt:
int, uint
short, ushort
char, uchar
...
SmallFloat128:
SmallLong
float128
SmallDouble:
SmallInt
double
SmallFloat:
float
binary16 (short float)
SmallComplexDouble:
SmallDouble
'_Complex double'
SmallComplexFloat:
SmallFloat
'_Complex float'
SmallQuat:
SmallComplexFloat
'__quatf' (quaternion)

SmallM64: (subtypes of "__m64")
__m64
__vec2f, __vec4h/__vec4sf, ...
__bcd64
...
SmallM128:
__m128
__vec4f, __vec2d, ...
__quatf
__bcd128
...

This mostly means that as-is, they will probably not auto-convert
to/from integer types (but manual casts will be supported).

The 'SmallWhatever' predicates mostly reflect types that accept a given
type or a logical subtype, and thus (implicitly) support auto-promotion
along those paths.


Click here to read the complete article
Re: Extended double precision decimal floating point

<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24870&group=comp.arch#24870

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:1cc4:b0:435:b8a0:1fe9 with SMTP id g4-20020a0562141cc400b00435b8a01fe9mr10807671qvd.54.1650830590730;
Sun, 24 Apr 2022 13:03:10 -0700 (PDT)
X-Received: by 2002:a05:6808:3086:b0:325:16a:1c25 with SMTP id
bl6-20020a056808308600b00325016a1c25mr3829575oib.117.1650830590497; Sun, 24
Apr 2022 13:03:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 24 Apr 2022 13:03:10 -0700 (PDT)
In-Reply-To: <t432di$5l6$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:7d26:c6b5:f025:1750;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:7d26:c6b5:f025:1750
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Sun, 24 Apr 2022 20:03:10 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Sun, 24 Apr 2022 20:03 UTC

On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:

> This is probably a lot more true of Binary FP than Decimal FP ...

It is true that since higher speed is attainable with binary FP,
that's what would be used for the truly speed-critical applications,
like, say, simulating the workings of a star.

But if you need decimal FP for serious work, like, say, a
commercial system that's handling a lot of transactions, you
would probably like it to run pretty fast too. And decimal
arithmetic can be speeded up using the same techniques as
applied to binary arithmetic, it just takes a few more transistors.

John Savard

Re: Extended double precision decimal floating point

<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24871&group=comp.arch#24871

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:27e6:b0:456:371f:3226 with SMTP id jt6-20020a05621427e600b00456371f3226mr1685598qvb.118.1650831786407;
Sun, 24 Apr 2022 13:23:06 -0700 (PDT)
X-Received: by 2002:a54:4e92:0:b0:325:224c:8ff7 with SMTP id
c18-20020a544e92000000b00325224c8ff7mr1435015oiy.154.1650831786226; Sun, 24
Apr 2022 13:23:06 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!3.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 24 Apr 2022 13:23:06 -0700 (PDT)
In-Reply-To: <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:f58c:845d:3446:dafc;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:f58c:845d:3446:dafc
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 24 Apr 2022 20:23:06 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 27
 by: MitchAlsup - Sun, 24 Apr 2022 20:23 UTC

On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
>
> > This is probably a lot more true of Binary FP than Decimal FP ...
> It is true that since higher speed is attainable with binary FP,
> that's what would be used for the truly speed-critical applications,
> like, say, simulating the workings of a star.
>
> But if you need decimal FP for serious work, like, say, a
> commercial system that's handling a lot of transactions, you
<
Assuming decimal arithmetic is 4× faster than decimal floating point::
Can you name a commercial system for which decimal arithmetic
is insufficient while decimal floating point would be sufficient ?
Remembering this is about speed and throughput.
<
> would probably like it to run pretty fast too. And decimal
> arithmetic can be speeded up using the same techniques as
> applied to binary arithmetic, it just takes a few more transistors.
<
Yes, but decimal fixed point can be made a LOT faster than decimal
floating point.
<
You see--it seems to me that; if the decimal fixed point has enough digits,
that commercial arithmetic is "fine" without needing the exponent(s)
that floating point brings to the <lack of> party.
>
> John Savard

Re: Extended double precision decimal floating point

<t44on4$qi3$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24872&group=comp.arch#24872

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 17:06:59 -0700
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <t44on4$qi3$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<t41kdg$sgn$1@dont-email.me> <t41la7$3hp$1@dont-email.me>
<t431u2$g0m$2@gioia.aioe.org> <t441u9$1uef$1@gal.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Apr 2022 00:07:01 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="98a0b84b007e3a3ac09e8f3d4e3fe53e";
logging-data="27203"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18wpX7cip6AhTAI5aGxEcyi"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:J9hdEQGplsPw4n4izaXYcTuoFhM=
In-Reply-To: <t441u9$1uef$1@gal.iecc.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 25 Apr 2022 00:06 UTC

On 4/24/2022 10:38 AM, John Levine wrote:
> According to Terje Mathisen <terje.mathisen@tmsw.no>:
>> Sorry, no, it never came up duing the 2016-2019 round afair.
>>
>> I strongly doubt Oracle's numbers though: Spending 40% here seems like a
>> clear case of badly written SW.
>
> Either that or the rest of the work was so trivial that the decimal emulation
> was all that was left.
>

Commercial work (aside from I/O is usually pretty trivial. Take $100
from your account - read the balance, a compare for balance avail and a
subtract, and write it back. The compare and the subtract are DFP, while
the get and put are trivial user-mode. Think about figuring a pay check,
or an invoice - Oracle's numbers seem plausible to me. Sure, if you
assume pre-scaling and don't do real (IEEE) DFP then it's less, but
that's not the question.

Re: Extended double precision decimal floating point

<t44p1d$ski$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24873&group=comp.arch#24873

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sun, 24 Apr 2022 17:12:28 -0700
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <t44p1d$ski$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 25 Apr 2022 00:12:29 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="98a0b84b007e3a3ac09e8f3d4e3fe53e";
logging-data="29330"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX189OmiaJhU5kq6JR6Yzkw/T"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:lCmbpOp68pVaB+0WBzHHAghY8JU=
In-Reply-To: <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 25 Apr 2022 00:12 UTC

On 4/24/2022 1:23 PM, MitchAlsup wrote:
> On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
>> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
>>
>>> This is probably a lot more true of Binary FP than Decimal FP ...
>> It is true that since higher speed is attainable with binary FP,
>> that's what would be used for the truly speed-critical applications,
>> like, say, simulating the workings of a star.
>>
>> But if you need decimal FP for serious work, like, say, a
>> commercial system that's handling a lot of transactions, you
> <
> Assuming decimal arithmetic is 4× faster than decimal floating point::
> Can you name a commercial system for which decimal arithmetic
> is insufficient while decimal floating point would be sufficient ?
> Remembering this is about speed and throughput.
> <
>> would probably like it to run pretty fast too. And decimal
>> arithmetic can be speeded up using the same techniques as
>> applied to binary arithmetic, it just takes a few more transistors.
> <
> Yes, but decimal fixed point can be made a LOT faster than decimal
> floating point.
> <
> You see--it seems to me that; if the decimal fixed point has enough digits,
> that commercial arithmetic is "fine" without needing the exponent(s)
> that floating point brings to the <lack of> party.

And binary integer is faster than BFP, so if you can track the exponent
yourself you should use fixed-point. For both binary and decimal, we let
the hardware keep track of the exponents because it's a pain to do it
manually.

Re: Extended double precision decimal floating point

<t44q07$171l$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24874&group=comp.arch#24874

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 00:28:55 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t44q07$171l$1@gal.iecc.com>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com> <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t44p1d$ski$1@dont-email.me>
Injection-Date: Mon, 25 Apr 2022 00:28:55 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="39989"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com> <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t44p1d$ski$1@dont-email.me>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Mon, 25 Apr 2022 00:28 UTC

According to Ivan Godard <ivan@millcomputing.com>:
>And binary integer is faster than BFP, so if you can track the exponent
>yourself you should use fixed-point.

Yeah, that's why von Neumann didn't put floating point in the IAS machine,
and probably why Amdahl's group did put it in the IBM 704.

--
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

Re: Extended double precision decimal floating point

<c86f3c77-6cf0-49e2-b609-5119fce2c772n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24875&group=comp.arch#24875

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:2aab:b0:446:4053:7a2b with SMTP id js11-20020a0562142aab00b0044640537a2bmr10949907qvb.127.1650848188456;
Sun, 24 Apr 2022 17:56:28 -0700 (PDT)
X-Received: by 2002:a05:6808:1514:b0:322:f961:5d9 with SMTP id
u20-20020a056808151400b00322f96105d9mr9996252oiw.126.1650848188254; Sun, 24
Apr 2022 17:56:28 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 24 Apr 2022 17:56:28 -0700 (PDT)
In-Reply-To: <t44p1d$ski$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:f58c:845d:3446:dafc;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:f58c:845d:3446:dafc
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t44p1d$ski$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c86f3c77-6cf0-49e2-b609-5119fce2c772n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 25 Apr 2022 00:56:28 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 43
 by: MitchAlsup - Mon, 25 Apr 2022 00:56 UTC

On Sunday, April 24, 2022 at 7:12:32 PM UTC-5, Ivan Godard wrote:
> On 4/24/2022 1:23 PM, MitchAlsup wrote:
> > On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
> >> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
> >>
> >>> This is probably a lot more true of Binary FP than Decimal FP ...
> >> It is true that since higher speed is attainable with binary FP,
> >> that's what would be used for the truly speed-critical applications,
> >> like, say, simulating the workings of a star.
> >>
> >> But if you need decimal FP for serious work, like, say, a
> >> commercial system that's handling a lot of transactions, you
> > <
> > Assuming decimal arithmetic is 4× faster than decimal floating point::
> > Can you name a commercial system for which decimal arithmetic
> > is insufficient while decimal floating point would be sufficient ?
> > Remembering this is about speed and throughput.
> > <
> >> would probably like it to run pretty fast too. And decimal
> >> arithmetic can be speeded up using the same techniques as
> >> applied to binary arithmetic, it just takes a few more transistors.
> > <
> > Yes, but decimal fixed point can be made a LOT faster than decimal
> > floating point.
> > <
> > You see--it seems to me that; if the decimal fixed point has enough digits,
> > that commercial arithmetic is "fine" without needing the exponent(s)
> > that floating point brings to the <lack of> party.
<
> And binary integer is faster than BFP, so if you can track the exponent
> yourself you should use fixed-point. For both binary and decimal, we let
> the hardware keep track of the exponents because it's a pain to do it
> manually.
<
I buy the argument that it is easier for HW to track the exponent when
it varies from -308..+308.
<
But the very vast majority of commercial decimal arithmetic have an
exponent of +2 or +3 (almost invariably fixed).

Re: Extended double precision decimal floating point

<c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24876&group=comp.arch#24876

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:2415:b0:69e:784d:3a4c with SMTP id d21-20020a05620a241500b0069e784d3a4cmr8938149qkn.14.1650855327851;
Sun, 24 Apr 2022 19:55:27 -0700 (PDT)
X-Received: by 2002:a05:6870:79a:b0:e9:109a:1391 with SMTP id
en26-20020a056870079a00b000e9109a1391mr3876421oab.105.1650855327571; Sun, 24
Apr 2022 19:55:27 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 24 Apr 2022 19:55:27 -0700 (PDT)
In-Reply-To: <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:7d26:c6b5:f025:1750;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:7d26:c6b5:f025:1750
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Mon, 25 Apr 2022 02:55:27 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 17
 by: Quadibloc - Mon, 25 Apr 2022 02:55 UTC

On Sunday, April 24, 2022 at 2:23:07 PM UTC-6, MitchAlsup wrote:

> Can you name a commercial system for which decimal arithmetic
> is insufficient while decimal floating point would be sufficient ?

I agree with you that for any commercial application that I can
think of, if decimal arithmetic is required, then integers will be
used. After all, floating-point will prevent proper rounding just as
effectively as the use of binary.

However, I assume applications for decimal floating-point do exist,
even if I don't know of them, or IBM would never have come up with
it.

The only use I can think of for DFP is spreadsheets, and, of course,
as they interact constantly with the user, high speed is not a requirement.

John Savard

Re: Extended double precision decimal floating point

<e1a0ed9a-c7a8-46c3-9d1a-2c097c723467n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24877&group=comp.arch#24877

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:b442:0:b0:69a:fc75:ca52 with SMTP id d63-20020a37b442000000b0069afc75ca52mr8921515qkf.730.1650858005625;
Sun, 24 Apr 2022 20:40:05 -0700 (PDT)
X-Received: by 2002:a05:6870:1601:b0:e1:9f71:29b8 with SMTP id
b1-20020a056870160100b000e19f7129b8mr6319048oae.125.1650858005300; Sun, 24
Apr 2022 20:40:05 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 24 Apr 2022 20:40:05 -0700 (PDT)
In-Reply-To: <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2607:fea8:1dde:6a00:1c1e:61be:4ce9:b9cb;
posting-account=QId4bgoAAABV4s50talpu-qMcPp519Eb
NNTP-Posting-Host: 2607:fea8:1dde:6a00:1c1e:61be:4ce9:b9cb
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e1a0ed9a-c7a8-46c3-9d1a-2c097c723467n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: robfi...@gmail.com (robf...@gmail.com)
Injection-Date: Mon, 25 Apr 2022 03:40:05 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 57
 by: robf...@gmail.com - Mon, 25 Apr 2022 03:40 UTC

On Sunday, April 24, 2022 at 10:55:29 PM UTC-4, Quadibloc wrote:
> On Sunday, April 24, 2022 at 2:23:07 PM UTC-6, MitchAlsup wrote:
>
> > Can you name a commercial system for which decimal arithmetic
> > is insufficient while decimal floating point would be sufficient ?
> I agree with you that for any commercial application that I can
> think of, if decimal arithmetic is required, then integers will be
> used. After all, floating-point will prevent proper rounding just as
> effectively as the use of binary.
>
> However, I assume applications for decimal floating-point do exist,
> even if I don't know of them, or IBM would never have come up with
> it.
>
> The only use I can think of for DFP is spreadsheets, and, of course,
> as they interact constantly with the user, high speed is not a requirement.
>
> John Savard

My decimal float multiplier takes up to about 400 clock cycles to complete a
128-bit multiply on random data. It uses repeated addition with shifting, the
standard algorithm. It is using an adder that takes three clocks per addition.
It skips over zeros though so for some inputs the multiplier is faster.
Multiplying 1x1 took about 40 clocks. If I can use an adder that takes only a
single clock cycle the multiplier would be three times as fast clock cycle wise.
But I suspect the fmax of the clock would suffer. I tried coding the add with
the 0x666… it turned out to be about 40 LOC to get a parameterized version.
It looks like it would be a two-cycle FPGA operation to keep a high fmax.
Doing the adds in one cycle and the mux to select outputs in the next.

Decimal float addition/subtraction takes about 35 clock cycles latency. In theory
it can start a new addition every clock cycle.

The decimal divider, using standard long form division, takes too long to be useful
in my opinion. It is something like 2,400 clock cycles to perform a divide. Software
using the multiplier and NR is about 2/3 as fast as the hardware solution and has
the better property of not affecting interrupt latency so much.

Compare is single clock cycle to do in hardware.

Definitely want to do compare, add/subtract and possibly multiply in hardware. The
hardware is probably an order of magnitude faster than software would be. It is a lot
of transistors but they are available.

Re: Extended double precision decimal floating point

<2022Apr25.082201@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24878&group=comp.arch#24878

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 06:22:01 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 30
Message-ID: <2022Apr25.082201@mips.complang.tuwien.ac.at>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com> <t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com> <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <t44p1d$ski$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="fa898341b02b22b9cb86425dd70c2a5d";
logging-data="11308"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/B+caHwMh9Ht9c3nTqC/Ud"
Cancel-Lock: sha1:736jey/41EuMW/5QD/CByyLXL+g=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 25 Apr 2022 06:22 UTC

Ivan Godard <ivan@millcomputing.com> writes:
>And binary integer is faster than BFP, so if you can track the exponent
>yourself you should use fixed-point. For both binary and decimal, we let
>the hardware keep track of the exponents because it's a pain to do it
>manually.

For commercial work it's usually determined by regulations what the
exponent is, and it is therefore easy; that's because the regulations
are based on the old times when people were computing by hand or with
mechanical calculators. E.g., you usually have to round to cents.
When converting between the old currency and Euro, the conversion
factor has 4 decimal digits behind the point. And so on.

Fixed point is therefore pretty straightforward for these kinds of
applications, you just have to make sure your numbers are long enough.

DFP looks like a solution looking for a problem (or for gullible
buyers) to me, and it's no wonder that nobody outside IBM has done a
hardware implementation, and that the software implementation by Intel
has not seen much (any) work in recent years. DFP also seems to be
more similar to fixed point than to real floating point in exponent
handling, probably because the applications actually want fixed point.

I wonder what makes DFP so interesting that so many posters here waste
their time on it.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Extended double precision decimal floating point

<2022Apr25.083641@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24879&group=comp.arch#24879

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 06:36:41 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 19
Message-ID: <2022Apr25.083641@mips.complang.tuwien.ac.at>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com> <980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com> <t432di$5l6$1@dont-email.me> <5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com> <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="fa898341b02b22b9cb86425dd70c2a5d";
logging-data="11308"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+BEddj7huv07FtJPjRb81i"
Cancel-Lock: sha1:+D5G7dDuNa3ohaMrav6Hm/asXg4=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 25 Apr 2022 06:36 UTC

Quadibloc <jsavard@ecn.ab.ca> writes:
>However, I assume applications for decimal floating-point do exist,
>even if I don't know of them, or IBM would never have come up with
>it.

IBM's application is to have a USP for their expensive machines that
their salesmen and buyers (however they were convinced to buy these
machines) can point to as a justification for the decision to buy
these machines.

>The only use I can think of for DFP is spreadsheets, and, of course,
>as they interact constantly with the user, high speed is not a requirement.

Are there any spreadsheet programs that use DFP?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Extended double precision decimal floating point

<t45ib0$j3g$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24880&group=comp.arch#24880

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Mon, 25 Apr 2022 00:24:15 -0700
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <t45ib0$j3g$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<8f909c18-cfe1-4748-8478-543bac50fdbbn@googlegroups.com>
<980ae858-467d-4b0a-8ef8-4a3fe990dd69n@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<t44p1d$ski$1@dont-email.me>
<c86f3c77-6cf0-49e2-b609-5119fce2c772n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 25 Apr 2022 07:24:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="98a0b84b007e3a3ac09e8f3d4e3fe53e";
logging-data="19568"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX191shJ5MeKIhdr4qzI0b9tc"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:++zcWmMepy54USlb9qmzanqf918=
In-Reply-To: <c86f3c77-6cf0-49e2-b609-5119fce2c772n@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 25 Apr 2022 07:24 UTC

On 4/24/2022 5:56 PM, MitchAlsup wrote:
> On Sunday, April 24, 2022 at 7:12:32 PM UTC-5, Ivan Godard wrote:
>> On 4/24/2022 1:23 PM, MitchAlsup wrote:
>>> On Sunday, April 24, 2022 at 3:03:12 PM UTC-5, Quadibloc wrote:
>>>> On Sunday, April 24, 2022 at 2:40:21 AM UTC-6, BGB wrote:
>>>>
>>>>> This is probably a lot more true of Binary FP than Decimal FP ...
>>>> It is true that since higher speed is attainable with binary FP,
>>>> that's what would be used for the truly speed-critical applications,
>>>> like, say, simulating the workings of a star.
>>>>
>>>> But if you need decimal FP for serious work, like, say, a
>>>> commercial system that's handling a lot of transactions, you
>>> <
>>> Assuming decimal arithmetic is 4× faster than decimal floating point::
>>> Can you name a commercial system for which decimal arithmetic
>>> is insufficient while decimal floating point would be sufficient ?
>>> Remembering this is about speed and throughput.
>>> <
>>>> would probably like it to run pretty fast too. And decimal
>>>> arithmetic can be speeded up using the same techniques as
>>>> applied to binary arithmetic, it just takes a few more transistors.
>>> <
>>> Yes, but decimal fixed point can be made a LOT faster than decimal
>>> floating point.
>>> <
>>> You see--it seems to me that; if the decimal fixed point has enough digits,
>>> that commercial arithmetic is "fine" without needing the exponent(s)
>>> that floating point brings to the <lack of> party.
> <
>> And binary integer is faster than BFP, so if you can track the exponent
>> yourself you should use fixed-point. For both binary and decimal, we let
>> the hardware keep track of the exponents because it's a pain to do it
>> manually.
> <
> I buy the argument that it is easier for HW to track the exponent when
> it varies from -308..+308.
> <
> But the very vast majority of commercial decimal arithmetic have an
> exponent of +2 or +3 (almost invariably fixed).

But intermediate results don't. 3.75% of $1721.25 is a product with a
different exponent, and the rules say whether you have to keep or round
in subsequent calculation. This is not precision-preserving like BFP. It
is really auto-scaled fixed point; calling it "floating point" is a
misnomer. At least the spec doesn't call it "exponent", it's "quantum".
Try thinking of it that way.

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor