Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Always draw your curves, then plot your reading.


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: IBM features, Extended double precision decimal floating point

<t4bqth$cjj$1@newsreader4.netcologne.de>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-f207-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: IBM features, Extended double precision decimal floating point
Date: Wed, 27 Apr 2022 16:27:29 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t4bqth$cjj$1@newsreader4.netcologne.de>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<t46ujj$7n3$1@newsreader4.netcologne.de> <t47icp$2lno$1@gal.iecc.com>
<t483n3$hf$1@newsreader4.netcologne.de> <t49kbt$2n4m$1@gal.iecc.com>
Injection-Date: Wed, 27 Apr 2022 16:27:29 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-f207-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:f207:0:7285:c2ff:fe6c:992d";
logging-data="12915"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Wed, 27 Apr 2022 16:27 UTC

John Levine <johnl@taugh.com> schrieb:
> According to Thomas Koenig <tkoenig@netcologne.de>:
>>> Possibly, but http potentially does deflate encoding for every request.
>>> If you're using your computer as a web server, you're going to do
>>> a whole lot of deflating.
>>
>>Sure, for a given computer, it could be useful both for file
>>compression and for http decoding.
>>
>>Given the huge disparity in price between a computer based on an
>>Intel or AMD CPU and a zSystem, I simply doubt that zSystems are
>>much used as web servers, where their high reliability (usually)
>>does not bring advantages to offset the higher cost.
>
> IBM sure seems to promote linux on Z as a high performance web server:
>
> https://www.ibm.com/downloads/cas/POB59BLE

Having read this, it's more a transatction server where the
transactions come in via https.

But you can call this a web server if you so desire ;-)

Re: IBM features, Extended double precision decimal floating point

<t4bqvv$cjj$2@newsreader4.netcologne.de>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-f207-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: IBM features, Extended double precision decimal floating point
Date: Wed, 27 Apr 2022 16:28:47 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t4bqvv$cjj$2@newsreader4.netcologne.de>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com>
<2022Apr25.083641@mips.complang.tuwien.ac.at> <t46mg6$27fl$1@gal.iecc.com>
<2022Apr26.224101@mips.complang.tuwien.ac.at>
<24374d50-bd90-41ac-88e3-8b9fa850d6d3n@googlegroups.com>
<2022Apr27.131221@mips.complang.tuwien.ac.at>
Injection-Date: Wed, 27 Apr 2022 16:28:47 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-f207-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:f207:0:7285:c2ff:fe6c:992d";
logging-data="12915"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Wed, 27 Apr 2022 16:28 UTC

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:

> Also, Thomas Koenig tells us that gcc converts the array notation into
> loops of scalar operations, and then, if you are lucky, the
> auto-vectorizer produces SIMD code from that.

Patches welcome.

Re: Extended double precision decimal floating point

<2022Apr27.181528@mips.complang.tuwien.ac.at>

 copy mid

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

 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: Wed, 27 Apr 2022 16:15:28 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 92
Message-ID: <2022Apr27.181528@mips.complang.tuwien.ac.at>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <jwvee1kkoni.fsf-monnier+comp.arch@gnu.org> <t48qqk$1bhh$1@gioia.aioe.org> <jwv1qxjyir3.fsf-monnier+comp.arch@gnu.org> <bc0883ee-9ea3-404a-8a69-556988acad6cn@googlegroups.com> <98806614-aa2d-4c7d-b6d4-081dd892c1cen@googlegroups.com> <2022Apr26.223557@mips.complang.tuwien.ac.at> <89119ea8-992f-41a1-9e6d-51f6df7712abn@googlegroups.com> <2022Apr27.154724@mips.complang.tuwien.ac.at> <bbcbad97-c906-42e6-9d11-ee3f6bb69d60n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="f90fc482fbc16649be01c1f23dcc5982";
logging-data="8986"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/yPuii7Y/plwXwaCqf2E7t"
Cancel-Lock: sha1:NJhkXo8ScA6sWzSKT4tPiJMdnbU=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 27 Apr 2022 16:15 UTC

Michael S <already5chosen@yahoo.com> writes:
>On Wednesday, April 27, 2022 at 5:36:59 PM UTC+3, Anton Ertl wrote:
>> ahu = ah & ~SIGNBIT;
>> bhu = bh & ~SIGNBIT;
>
>I'd expect a sign to be stored separately rather than with MS word.
>It shouldn't be hard to find a "free" room for a single bit in header/metadata
>area.

Unless you use a complete byte for the sign bit, the overhead is the
same as in the code I showed. And if you use a complete byte, you
have to load these bytes, and store the result byte, which is also
overhead.

>> c1 = umul(al,bl);
>> c2 = umul(ahu,bl);
>> c3 = umul(al,bhu);
>> c4 = umul(ahu,bhu);
>> c = c4<<(2*wordwidth) + (c3+c2)<<wordwidth + c1;
>> c = c | (((ah^bh)&SIGNBIT)<<(3*wordwidth);
>>
>> Admittedly the overhead of sign-magnitude is independent of the width
>> of a and b,
>
>Or no overhead at all, when sign not stored with limb.

No overhead only if you don't deal with signs.

>I am more concerned with complication than with speed impact.

The complication is minor.

>> OTOH two's-complement addition is cheaper
>> than sign-magnitude addition. Plus, I think that for most signed
>> bigint operations the involved lengths are 1;
>
>Does not sound obvious.

The only use for signed Bigints I know is for the Bigint type of
high-level languages. Given that most integers are small, the typical
Bigint is one word in length. There are also high-level languages
that have short ints that automatically extend to Bigints on short int
overflow. In that case Bigints are rare, but they may have a minimum
(and typical) length of 2 if a short int fills all of a word.

>> I am too lazy to think through how a mixed signed-unsigned would help.
>> Would it be as simple as:
>>
>> c1 = uumul(al,bl);
>> c2 = sumul(ah,bl);
>> c3 = usmul(al,bh);
>> c4 = ssmul(ah,bh);
>> c = c4<<(2*wordwidth) + (c3+c2)<<wordwidth + c1;
>>
>> ?
>
>Yes, you got the idea.
>For arbitrary length, utilizing mixed multiplication would be rather
>complicated, with main complication related to handling of carry/borrow,

If the above is correct, what is the problem in extending it to
arbitrary length? I.e., always use uumul(unsigned, unsigned),
sumul(signed, unsigned), usmul(unsigned, signed) and ssmul(signed,
signed). In the end, add up the two-word-wide intermediate results.

I suspect that the adding-up requires sign-extending intermediate
signed results to full length, though; or the equivalent dealing with
carry/borrow (if possible); is that what you are referring to above?

>but if done right it can spare you of O(n+m) overhead.
>However, why bother? Just use sign-magnitude format!

And have the sign-magnitude overhead for addition and subtraction.

>> In that case, the absense of such an instruction is probably due to
>> the shortness of typical signed big integers.
>
>IMO, , at least for architectures that were defined more recently (30-35 years),
>a difficulty of mapping it into HLL was more important factor.

Actually high-level-languages all have Bigints, in contrast to many
other things for which there are instructions.

>May be, there are cases where it helps elliptic curves cryptography?

Cryptography tends to work with unsigned wide (fixed-width) integers.
I have not looked at ECC, though.

- 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

<72ce75a2-21ef-4e4f-8304-0cee0921a8bbn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:7fcc:0:b0:2f2:5bf:6c with SMTP id b12-20020ac87fcc000000b002f205bf006cmr20023594qtk.655.1651081335473;
Wed, 27 Apr 2022 10:42:15 -0700 (PDT)
X-Received: by 2002:a54:4f83:0:b0:324:f58f:4b95 with SMTP id
g3-20020a544f83000000b00324f58f4b95mr11404763oiy.4.1651081335272; Wed, 27 Apr
2022 10:42:15 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!nntp.club.cc.cmu.edu!45.76.7.193.MISMATCH!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: Wed, 27 Apr 2022 10:42:15 -0700 (PDT)
In-Reply-To: <2022Apr27.181528@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:513a:b934:3f73:3d07;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:513a:b934:3f73:3d07
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<jwvee1kkoni.fsf-monnier+comp.arch@gnu.org> <t48qqk$1bhh$1@gioia.aioe.org>
<jwv1qxjyir3.fsf-monnier+comp.arch@gnu.org> <bc0883ee-9ea3-404a-8a69-556988acad6cn@googlegroups.com>
<98806614-aa2d-4c7d-b6d4-081dd892c1cen@googlegroups.com> <2022Apr26.223557@mips.complang.tuwien.ac.at>
<89119ea8-992f-41a1-9e6d-51f6df7712abn@googlegroups.com> <2022Apr27.154724@mips.complang.tuwien.ac.at>
<bbcbad97-c906-42e6-9d11-ee3f6bb69d60n@googlegroups.com> <2022Apr27.181528@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <72ce75a2-21ef-4e4f-8304-0cee0921a8bbn@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 27 Apr 2022 17:42:15 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 102
 by: MitchAlsup - Wed, 27 Apr 2022 17:42 UTC

On Wednesday, April 27, 2022 at 11:38:53 AM UTC-5, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >On Wednesday, April 27, 2022 at 5:36:59 PM UTC+3, Anton Ertl wrote:
> >> ahu = ah & ~SIGNBIT;
> >> bhu = bh & ~SIGNBIT;
> >
> >I'd expect a sign to be stored separately rather than with MS word.
> >It shouldn't be hard to find a "free" room for a single bit in header/metadata
> >area.
>
> Unless you use a complete byte for the sign bit, the overhead is the
> same as in the code I showed. And if you use a complete byte, you
> have to load these bytes, and store the result byte, which is also
> overhead.
>
> >> c1 = umul(al,bl);
> >> c2 = umul(ahu,bl);
> >> c3 = umul(al,bhu);
> >> c4 = umul(ahu,bhu);
> >> c = c4<<(2*wordwidth) + (c3+c2)<<wordwidth + c1;
> >> c = c | (((ah^bh)&SIGNBIT)<<(3*wordwidth);
> >>
> >> Admittedly the overhead of sign-magnitude is independent of the width
> >> of a and b,
> >
> >Or no overhead at all, when sign not stored with limb.
>
> No overhead only if you don't deal with signs.
>
> >I am more concerned with complication than with speed impact.
>
> The complication is minor.
>
> >> OTOH two's-complement addition is cheaper
> >> than sign-magnitude addition. Plus, I think that for most signed
> >> bigint operations the involved lengths are 1;
> >
> >Does not sound obvious.
>
> The only use for signed Bigints I know is for the Bigint type of
> high-level languages. Given that most integers are small, the typical
> Bigint is one word in length. There are also high-level languages
> that have short ints that automatically extend to Bigints on short int
> overflow. In that case Bigints are rare, but they may have a minimum
> (and typical) length of 2 if a short int fills all of a word.
>
> >> I am too lazy to think through how a mixed signed-unsigned would help.
> >> Would it be as simple as:
> >>
> >> c1 = uumul(al,bl);
> >> c2 = sumul(ah,bl);
> >> c3 = usmul(al,bh);
> >> c4 = ssmul(ah,bh);
> >> c = c4<<(2*wordwidth) + (c3+c2)<<wordwidth + c1;
> >>
> >> ?
> >
> >Yes, you got the idea.
> >For arbitrary length, utilizing mixed multiplication would be rather
> >complicated, with main complication related to handling of carry/borrow,
>
> If the above is correct, what is the problem in extending it to
> arbitrary length? I.e., always use uumul(unsigned, unsigned),
> sumul(signed, unsigned), usmul(unsigned, signed) and ssmul(signed,
> signed). In the end, add up the two-word-wide intermediate results.
>
> I suspect that the adding-up requires sign-extending intermediate
> signed results to full length, though; or the equivalent dealing with
> carry/borrow (if possible); is that what you are referring to above?
>
> >but if done right it can spare you of O(n+m) overhead.
> >However, why bother? Just use sign-magnitude format!
>
> And have the sign-magnitude overhead for addition and subtraction.
>
> >> In that case, the absense of such an instruction is probably due to
> >> the shortness of typical signed big integers.
> >
> >IMO, , at least for architectures that were defined more recently (30-35 years),
> >a difficulty of mapping it into HLL was more important factor.
>
> Actually high-level-languages all have Bigints, in contrast to many
> other things for which there are instructions.
>
> >May be, there are cases where it helps elliptic curves cryptography?
>
> Cryptography tends to work with unsigned wide (fixed-width) integers.
> I have not looked at ECC, though.
<
SECDED works with 2^n+n+2 containers.
n=6 -> 64-bits + 8-bits.
SECDED on 64-bits uses a 128-bit code matrix and uses the 72-bit subset.
<
Thus, ECC usually works on non-power of 2 sizes, or degenerate next power of
2 sizes.
<
There are higher forms of ECC that use "exotic" "arithmetic". DECTED,...
<
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Re: IBM features, Extended double precision decimal floating point

<hifaK.672704$LN2.4978@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!50.7.236.10.MISMATCH!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.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: IBM features, Extended double precision decimal floating point
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com> <26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com> <c64714c1-ec97-4ac4-871b-63578dd8cf1dn@googlegroups.com> <2022Apr25.083641@mips.complang.tuwien.ac.at> <t46mg6$27fl$1@gal.iecc.com> <2022Apr26.224101@mips.complang.tuwien.ac.at> <24374d50-bd90-41ac-88e3-8b9fa850d6d3n@googlegroups.com> <AvcaK.379162$f2a5.77570@fx48.iad>
In-Reply-To: <AvcaK.379162$f2a5.77570@fx48.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 84
Message-ID: <hifaK.672704$LN2.4978@fx13.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Wed, 27 Apr 2022 17:44:45 UTC
Date: Wed, 27 Apr 2022 13:43:20 -0400
X-Received-Bytes: 4936
 by: EricP - Wed, 27 Apr 2022 17:43 UTC

EricP wrote:
> MitchAlsup wrote:
>> On Tuesday, April 26, 2022 at 3:50:38 PM UTC-5, Anton Ertl wrote:
>>> John Levine <jo...@taugh.com> writes:
>>>> New models of the z series have had some oddly specific addtions,
>>>> like the DEFLATE instruction that does the inner part of gzip and
>>>> the digital signature instruction that does elliptic curve signing
>>>> and verifying. I realize those are both reasonably common in web
>>>> servers but it'd surprise me if they were enough of a bottleneck to
>>>> merit putting them in microcode.
>> <
>>> The question is what benefit microcode buys over architectural code.
>>> If you do just the same things, microcode is not any faster on
>>> current machines.
>> <
>> You can microcode the execution pipeline
>> OR
>> You can microcode a function unit
>> When you microcode a function unit, every other function unit is free
>> to run
>> other code while one function unit crunches on its current instruction.
>> <
>> Microcoding the execution pipeline has (deservedly) fallen out of
>> fashion.
>> {AND:: One can call microcoding of a function unit to simply be
>> sequencing--
>> where it gets fuzzy is when you sequence a pair of function units to
>> operate
>> on one instruction using the joint set of resources.}
>
> In this case IBM refers to both Deflate and Crypto features as
> "accelerators" which I suspect is IBM-speak for "even though the hardware
> is already present in your machine, we charge extra to enable this".
>
> While their operations may be triggered by a single ISA instruction,
> given the complex nature of each function it seems possible they can be
> internally implemented to be operating on multiple macro-instructions
> at once from separate threads, and within each could be multiple
> pipelines states, and use logic to accelerate each state.
>
> Certainly DEFLATE operates on a block of memory.
> While Crypto might operate on a large register blob,
> it seems most likely to be a memory block too.
>
> In which case the amount of concurrency available would be dictated
> by the local memory coherency rules for individual instructions
> similar to block string move instructions.
>
> How many of these fancy memory block operations can be going
> at once would be decided by how much LSQ disambiguation can be done,
> against normal loads and stores, and against other memory block operations.
>
> For example, if each memory block instruction stuffs an
> "I'm working on this 4kB block" entry into the LSQ,
> then it could be disambiguated similar to a 64B cache line,
> and operations on separate blocks allowed to proceed concurrently
> without violating any of the local memory consistency rules.
>
> That in turn decides how many concurrent macro-instructions
> the accelerators can potentially handle.

It might be easier if memory block instructions were defined like async IO
- that the input and output buffers are considered "in use" and must not
be touched or modified until the full operation completes.

Like async IO, it is software's responsibility to not trip over
its own feet on this. Otherwise it is defined as undefined.

This definition would allow multiple concurrent internal memory block
operations to be launched at once, most likely in multiple threads
arranged to operate on a pipeline of buffers.

So one could have a set of threads to transmit or backup files do
IO read-ahead on a file buffer, deflate it, encrypt it,
IO write-behind to network or backup device.

Each of these multiple block moves, deflates, and encrypts operates
concurrently but only needs to worry about its own virtual memory blocks.

That eliminates the need to check for overlaps to the memory blocks
to other blocks or regular load or store instructions.

Re: Extended double precision decimal floating point

<t4c1qq$ukj$1@dont-email.me>

 copy mid

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

 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: Wed, 27 Apr 2022 13:25:24 -0500
Organization: A noiseless patient Spider
Lines: 282
Message-ID: <t4c1qq$ukj$1@dont-email.me>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<t45m4t$1057$1@gioia.aioe.org> <jwvee1kkoni.fsf-monnier+comp.arch@gnu.org>
<t48qqk$1bhh$1@gioia.aioe.org> <jwv1qxjyir3.fsf-monnier+comp.arch@gnu.org>
<bc0883ee-9ea3-404a-8a69-556988acad6cn@googlegroups.com>
<98806614-aa2d-4c7d-b6d4-081dd892c1cen@googlegroups.com>
<2022Apr26.223557@mips.complang.tuwien.ac.at>
<89119ea8-992f-41a1-9e6d-51f6df7712abn@googlegroups.com>
<2022Apr27.154724@mips.complang.tuwien.ac.at>
<bbcbad97-c906-42e6-9d11-ee3f6bb69d60n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 27 Apr 2022 18:25:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="9a5b4e9d202533f8d668ce79bab07cb7";
logging-data="31379"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ILf5H+d3eNzP0oI8pmswj"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:qLEi9Fx/eRCKYr4LXnlykH9bzaU=
In-Reply-To: <bbcbad97-c906-42e6-9d11-ee3f6bb69d60n@googlegroups.com>
Content-Language: en-US
 by: BGB - Wed, 27 Apr 2022 18:25 UTC

On 4/27/2022 10:51 AM, Michael S wrote:
> On Wednesday, April 27, 2022 at 5:36:59 PM UTC+3, Anton Ertl wrote:
>> Michael S <already...@yahoo.com> writes:
>>> On Tuesday, April 26, 2022 at 11:40:55 PM UTC+3, Anton Ertl wrote:
>>>> Michael S <already...@yahoo.com> writes:
>>>> [reformatted for conventional Usenet line length]
>>>>> Another reason to prefer sign-magnitude over two-complement as
>>>>> internal format for Big Integer library is weak support for mixed
>>>>> signed-unsigned arithmetic in many instruction sets and even worse
>>>>> support in all popular HLLs that are likely candidates for
>>>>> implementation language of Big Integer libraries.
>>>> I don't see why you would need such instructions for implementing
>>>> twos-complement big-integers.
>>>>
>>>> I don't see a single reason for sign-magnitude big-integer
>>>> representation.
>> ...
>> [Again, reformatted]
>>> So, what would be your code for, say, multiplication, when numbers
>>> are stored as two-complements? Can you sketch it here? Leave away
>>> management, memory allocation, prescaling, postscaling, etc... Just
>>> show two inner loops of convolution.
>> Why would big-integer arithmetic have any scaling?
>
> Pre-scaling likely not needed, at least for multiplication.
> Post-scaling is because upfront you don't know an exact number of words in
> result. If the number is stored with LS word first then post-scaling only needs
> to update metadata. But for data stored with MS word first it can require
> a word shift.
>

Don't do this.

This is a case where low-high ordering makes more sense.

>>
>> For multiplication, multiplying a two-word integer a with a two-word
>> integer b (giving a four-word integer c) should display all the
>> interesting cases, so I'll show that.
>>
>> c1,c2,c3,c4 are two-word values
>> al and ah are the low and high words of a; likewise for bl and bh
>> umul is an unsigned multiplication of two words, with a two-word result
>
> Complication of 2c is more obvious when length of inputs and outputs is variable.
> But as example, 2x2 will do.
>

You could simplify things by making all of the bignums be power-of-2
sizes, and by padding inputs to the same size in cases where they differ.

An alternative (more relevant to _BitInt) is to expand both to the
destination width first and then do the multiply.

Though, _BitInt doesn't expand to Len1+Len2, but rather Max(Len1,Len2).

In my case, underlying Storage for _BitInt(N) is, effectively:
1.. 8: int8_t/uint8_t (char)
9.. 16: int16_t/uint16_t (short)
17.. 32: int32_t/uint32_t (int)
33.. 64: int64_t/uint64_t (long long)
65..128: int128_t/uint128_t (__int128)
129+: Pad to a multiple of 128 bits.

They were not forced to power-of-2 in this case, so, eg:
256, 384, 512, 640, ...

One could argue whether power-of-2 would be better, however, it would be
slower, and at these large sizes, the memory cost is big enough to where
power-of-2 vs non-power-of-2 might be noticeable.

Signed values remained twos complement.

At the ABI level, these larger sizes were handled similarly to structs
(pass by reference and copy as needed).

If I added a _Decimal(N) type, it would likely be similar:
1..16: __bcd64 (64b storage)
17..32: __bcd128 (128b storage)
33+: Pad to a multiple of 128-bits (32 digits).

Though, a more generalized _Decimal(N,P) type would have the issue that
now the type also needs to encode a decimal point.

I could cut off some-odd bits from the length to encode the location of
the decimal point.

As-is, BitInt is encoded (in the typesystem) like an array, just with
the array length encoding the length of the bit-vector (rather than a
number of elements of the base type).

However, modest size 1D arrays are encoded directly as a bit-field
within the "type ID word", whereas 2D arrays need to be encoded via the
"type overflow table" (itself a finite size).

So, it is preferable to leave it encoded like it were a 1D array.
It is possible multiple base-types could be used to encode how many bits
are cut off, say:
TY_DECIMAL_P0 //0 bits for decimal point (max=4095 digits, pt=0)
TY_DECIMAL_P4 //4 bits for decimal point (max=255 digits, pt=0..15)
TY_DECIMAL_P6 //6 bits for decimal point (max=63 digits, pt=0..63)
TY_DECIMAL_PA //Encoded as a 2D array

Note that for arrays of these types, these would invariably need to use
the overflow table.

Sign for signed decimal numbers would most likely be 10s complement.

Probably not really a compelling reason to justify storage sizes smaller
than 64 bits for this.

>>
>> c1 = umul(al,bl);
>> c2 = umul(ah,bl);
>> c3 = umul(al,bh);
>> c4 = umul(ah,bh);
>> if (signbit(ah))
>> c4 -= b;
>> if (signbit(bh))
>> c4 -= a;
>> c = c4<<(2*wordwidth) + (c3+c2)<<wordwidth + c1;
>>
>> I leave it to you to map the last line efficiently onto the
>> architecture at hand. And of course you want to eliminate the top
>> word of c if it is just a sign extension of the next word.
>
> Yes, that's one possible trick. Relatively simple, but not free in runtime cost.
> Esp. non-free when at least one of operands is short.
>

Say, you do 256*128, pre-expand the latter to 256, and then do a 256*256
multiply...

And/or special-case it...

>>
>> For comparison, here is the sign-magnitude counterpart:
>>
>> ahu = ah & ~SIGNBIT;
>> bhu = bh & ~SIGNBIT;
>
> I'd expect a sign to be stored separately rather than with MS word.
> It shouldn't be hard to find a "free" room for a single bit in header/metadata
> area.
>

That probably makes more sense for a format that is variable-length at
runtime, rather than for formats that are fixed-length at compile time.

Though, if one uses a sign byte, they might also use it to store the size.

One big/ugly issue with variable-length types though is that now one
needs to deal with memory management for them.

Granted, this is where something like an "alloca" mechanism makes sense,
rather than malloc'ing them and potentially having them leak.

Though, in my case, the alloca mechanism is built on top of malloc
internally, it will put them in a linked list and automatically free
anything in the list when the function returns.

This still leaves a problem though for big-integer types in globals or
in structures.

This is less of an issue for something like _BitInt(N) as the size is
known at compile time (and it can be stored in-place).

>> c1 = umul(al,bl);
>> c2 = umul(ahu,bl);
>> c3 = umul(al,bhu);
>> c4 = umul(ahu,bhu);
>> c = c4<<(2*wordwidth) + (c3+c2)<<wordwidth + c1;
>> c = c | (((ah^bh)&SIGNBIT)<<(3*wordwidth);
>>
>> Admittedly the overhead of sign-magnitude is independent of the width
>> of a and b,
>
> Or no overhead at all, when sign not stored with limb.
>
>> while the subtractions get more expensive with longer a
>> and longer b (but the number of multiplies grows with
>> length(a)*length(b), while the overhead of the subtractions grows only
>> with length(a)+length(b).
>
> I am more concerned with complication than with speed impact.
>
>> OTOH two's-complement addition is cheaper
>> than sign-magnitude addition. Plus, I think that for most signed
>> bigint operations the involved lengths are 1;
>
> Does not sound obvious.
>
>> one could special-case
>> that by using smul and leaving the subtractions away.
>>
>> I am too lazy to think through how a mixed signed-unsigned would help.
>> Would it be as simple as:
>>
>> c1 = uumul(al,bl);
>> c2 = sumul(ah,bl);
>> c3 = usmul(al,bh);
>> c4 = ssmul(ah,bh);
>> c = c4<<(2*wordwidth) + (c3+c2)<<wordwidth + c1;
>>
>> ?
>
> Yes, you got the idea.
> For arbitrary length, utilizing mixed multiplication would be rather
> complicated, with main complication related to handling of carry/borrow,
> but if done right it can spare you of O(n+m) overhead.
> However, why bother? Just use sign-magnitude format!
>

This is unnecessary, when the former strategy (just use unsigned
multiplies and then special-case the high-end results) also works well
enough.

Sign-magnitude would also be annoyingly out of place on a system where
pretty much everything else (excluding FPU types) is twos complement.

Someone could almost make a case for a 1s complement FP format:
Positive numbers: Encoded as in IEEE-754;
Negative numbers: All bits inverted.


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

<7e16104b-17a2-4bd0-9c4b-b80fcf79deadn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:296:b0:2f3:6b72:89dc with SMTP id z22-20020a05622a029600b002f36b7289dcmr10145249qtw.670.1651084532430;
Wed, 27 Apr 2022 11:35:32 -0700 (PDT)
X-Received: by 2002:a9d:17cb:0:b0:604:350:7fd3 with SMTP id
j69-20020a9d17cb000000b0060403507fd3mr10869013otj.291.1651084532202; Wed, 27
Apr 2022 11:35:32 -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: Wed, 27 Apr 2022 11:35:32 -0700 (PDT)
In-Reply-To: <72ce75a2-21ef-4e4f-8304-0cee0921a8bbn@googlegroups.com>
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>
<jwvee1kkoni.fsf-monnier+comp.arch@gnu.org> <t48qqk$1bhh$1@gioia.aioe.org>
<jwv1qxjyir3.fsf-monnier+comp.arch@gnu.org> <bc0883ee-9ea3-404a-8a69-556988acad6cn@googlegroups.com>
<98806614-aa2d-4c7d-b6d4-081dd892c1cen@googlegroups.com> <2022Apr26.223557@mips.complang.tuwien.ac.at>
<89119ea8-992f-41a1-9e6d-51f6df7712abn@googlegroups.com> <2022Apr27.154724@mips.complang.tuwien.ac.at>
<bbcbad97-c906-42e6-9d11-ee3f6bb69d60n@googlegroups.com> <2022Apr27.181528@mips.complang.tuwien.ac.at>
<72ce75a2-21ef-4e4f-8304-0cee0921a8bbn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7e16104b-17a2-4bd0-9c4b-b80fcf79deadn@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: already5...@yahoo.com (Michael S)
Injection-Date: Wed, 27 Apr 2022 18:35:32 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 111
 by: Michael S - Wed, 27 Apr 2022 18:35 UTC

On Wednesday, April 27, 2022 at 8:42:17 PM UTC+3, MitchAlsup wrote:
> On Wednesday, April 27, 2022 at 11:38:53 AM UTC-5, Anton Ertl wrote:
> > Michael S <already...@yahoo.com> writes:
> > >On Wednesday, April 27, 2022 at 5:36:59 PM UTC+3, Anton Ertl wrote:
> > >> ahu = ah & ~SIGNBIT;
> > >> bhu = bh & ~SIGNBIT;
> > >
> > >I'd expect a sign to be stored separately rather than with MS word.
> > >It shouldn't be hard to find a "free" room for a single bit in header/metadata
> > >area.
> >
> > Unless you use a complete byte for the sign bit, the overhead is the
> > same as in the code I showed. And if you use a complete byte, you
> > have to load these bytes, and store the result byte, which is also
> > overhead.
> >
> > >> c1 = umul(al,bl);
> > >> c2 = umul(ahu,bl);
> > >> c3 = umul(al,bhu);
> > >> c4 = umul(ahu,bhu);
> > >> c = c4<<(2*wordwidth) + (c3+c2)<<wordwidth + c1;
> > >> c = c | (((ah^bh)&SIGNBIT)<<(3*wordwidth);
> > >>
> > >> Admittedly the overhead of sign-magnitude is independent of the width
> > >> of a and b,
> > >
> > >Or no overhead at all, when sign not stored with limb.
> >
> > No overhead only if you don't deal with signs.
> >
> > >I am more concerned with complication than with speed impact.
> >
> > The complication is minor.
> >
> > >> OTOH two's-complement addition is cheaper
> > >> than sign-magnitude addition. Plus, I think that for most signed
> > >> bigint operations the involved lengths are 1;
> > >
> > >Does not sound obvious.
> >
> > The only use for signed Bigints I know is for the Bigint type of
> > high-level languages. Given that most integers are small, the typical
> > Bigint is one word in length. There are also high-level languages
> > that have short ints that automatically extend to Bigints on short int
> > overflow. In that case Bigints are rare, but they may have a minimum
> > (and typical) length of 2 if a short int fills all of a word.
> >
> > >> I am too lazy to think through how a mixed signed-unsigned would help.
> > >> Would it be as simple as:
> > >>
> > >> c1 = uumul(al,bl);
> > >> c2 = sumul(ah,bl);
> > >> c3 = usmul(al,bh);
> > >> c4 = ssmul(ah,bh);
> > >> c = c4<<(2*wordwidth) + (c3+c2)<<wordwidth + c1;
> > >>
> > >> ?
> > >
> > >Yes, you got the idea.
> > >For arbitrary length, utilizing mixed multiplication would be rather
> > >complicated, with main complication related to handling of carry/borrow,
> >
> > If the above is correct, what is the problem in extending it to
> > arbitrary length? I.e., always use uumul(unsigned, unsigned),
> > sumul(signed, unsigned), usmul(unsigned, signed) and ssmul(signed,
> > signed). In the end, add up the two-word-wide intermediate results.
> >
> > I suspect that the adding-up requires sign-extending intermediate
> > signed results to full length, though; or the equivalent dealing with
> > carry/borrow (if possible); is that what you are referring to above?
> >
> > >but if done right it can spare you of O(n+m) overhead.
> > >However, why bother? Just use sign-magnitude format!
> >
> > And have the sign-magnitude overhead for addition and subtraction.
> >
> > >> In that case, the absense of such an instruction is probably due to
> > >> the shortness of typical signed big integers.
> > >
> > >IMO, , at least for architectures that were defined more recently (30-35 years),
> > >a difficulty of mapping it into HLL was more important factor.
> >
> > Actually high-level-languages all have Bigints, in contrast to many
> > other things for which there are instructions.
> >
> > >May be, there are cases where it helps elliptic curves cryptography?
> >
> > Cryptography tends to work with unsigned wide (fixed-width) integers.
> > I have not looked at ECC, though.
> <
> SECDED works with 2^n+n+2 containers.

Other ECC.
Not Error Correction Codes, but Elliptic Curve Cryptography

> n=6 -> 64-bits + 8-bits.
> SECDED on 64-bits uses a 128-bit code matrix and uses the 72-bit subset.
> <
> Thus, ECC usually works on non-power of 2 sizes, or degenerate next power of
> 2 sizes.
> <
> There are higher forms of ECC that use "exotic" "arithmetic". DECTED,...

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

Re: Extended double precision decimal floating point

<t4c70m$1an6$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!EhtdJS5E9ITDZpJm3Uerlg.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: Wed, 27 Apr 2022 21:53:59 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t4c70m$1an6$1@gioia.aioe.org>
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>
<t45m4t$1057$1@gioia.aioe.org> <jwvee1kkoni.fsf-monnier+comp.arch@gnu.org>
<t48qqk$1bhh$1@gioia.aioe.org> <jwv1qxjyir3.fsf-monnier+comp.arch@gnu.org>
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="43750"; posting-host="EhtdJS5E9ITDZpJm3Uerlg.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 - Wed, 27 Apr 2022 19:53 UTC

Stefan Monnier wrote:
> Terje Mathisen [2022-04-26 15:07:35] wrote:
>> Stefan Monnier wrote:
>>>> This is the crux right here: Fixed-point decimal, using unsigned binary
>>>> variables and external scale, will almost always be faster than both binary
>>>> FP and decimal FP, but you need to hand-code (or get your compiler to do it
>>>> for you?) every individual operation.
>>> Why *unsigned* binary?
>> Because you have to work with arrays of words, and I really don't want those
>> words to be signed!
>
> Are sorry. You were talking about the unsigned fixed size integers
> inside the bignums (what GMP calls the "limbs" IIRC), where I was
> thinking about the bignums themselves.

One of the key differences between BID and GMP is that the 128-bit
binary decimal fp is exactly specified, and the 128-bit size if fixed
and will therefore always fit in two 64-bit (unsigned) regs.

GMPs limbs are by definition the individual (also unsigned) elements of
variable length arrays.

Terje

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

Re: Extended double precision decimal floating point

<t4c77d$1an6$2@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!EhtdJS5E9ITDZpJm3Uerlg.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: Wed, 27 Apr 2022 21:57:34 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t4c77d$1an6$2@gioia.aioe.org>
References: <d1790e73-11b1-497d-abd0-a349fedf750cn@googlegroups.com>
<t432di$5l6$1@dont-email.me>
<5188795c-42a7-45d4-8243-f4bbaa3a96a9n@googlegroups.com>
<26231a57-6317-4c08-8c37-4508ac3e0a6en@googlegroups.com>
<t45m4t$1057$1@gioia.aioe.org> <jwvee1kkoni.fsf-monnier+comp.arch@gnu.org>
<t48qqk$1bhh$1@gioia.aioe.org> <jwv1qxjyir3.fsf-monnier+comp.arch@gnu.org>
<bc0883ee-9ea3-404a-8a69-556988acad6cn@googlegroups.com>
<98806614-aa2d-4c7d-b6d4-081dd892c1cen@googlegroups.com>
<2022Apr26.223557@mips.complang.tuwien.ac.at>
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="43750"; posting-host="EhtdJS5E9ITDZpJm3Uerlg.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 - Wed, 27 Apr 2022 19:57 UTC

Anton Ertl wrote:
> Michael S <already5chosen@yahoo.com> writes:
> [reformatted for conventional Usenet line length]
>> Another reason to prefer sign-magnitude over two-complement as
>> internal format for Big Integer library is weak support for mixed
>> signed-unsigned arithmetic in many instruction sets and even worse
>> support in all popular HLLs that are likely candidates for
>> implementation language of Big Integer libraries.
>
> I don't see why you would need such instructions for implementing
> twos-complement big-integers.
>
> I don't see a single reason for sign-magnitude big-integer
> representation.

OK.

I accept that it does work to keep everything in twos-complement, but in
my own libraires I've found it easier to keep the signs separate, partly
because that makes it much easier to compare the magnitude of two numbers.

Terje

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

Re: Extended double precision decimal floating point

<t4f1sa$nhu$1@dont-email.me>

 copy mid

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

 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: Thu, 28 Apr 2022 16:44:36 -0500
Organization: A noiseless patient Spider
Lines: 128
Message-ID: <t4f1sa$nhu$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>
<t45m4t$1057$1@gioia.aioe.org> <jwvee1kkoni.fsf-monnier+comp.arch@gnu.org>
<t48qqk$1bhh$1@gioia.aioe.org> <jwv1qxjyir3.fsf-monnier+comp.arch@gnu.org>
<t4c70m$1an6$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 28 Apr 2022 21:44:43 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="c2bf31da531e71a90165518572bfc286";
logging-data="24126"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+9OgZTJqS5yV3G5GYXIIT7"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:OEZD4eCvsKHa1mtmiEOYcJxkxkI=
In-Reply-To: <t4c70m$1an6$1@gioia.aioe.org>
Content-Language: en-US
 by: BGB - Thu, 28 Apr 2022 21:44 UTC

On 4/27/2022 2:53 PM, Terje Mathisen wrote:
> Stefan Monnier wrote:
>> Terje Mathisen [2022-04-26 15:07:35] wrote:
>>> Stefan Monnier wrote:
>>>>> This is the crux right here: Fixed-point decimal, using unsigned
>>>>> binary
>>>>> variables and external scale, will almost always be faster than
>>>>> both binary
>>>>> FP and decimal FP, but you need to hand-code (or get your compiler
>>>>> to do it
>>>>> for you?) every individual operation.
>>>> Why *unsigned* binary?
>>> Because you have to work with arrays of words, and I really don't
>>> want those
>>> words to be signed!
>>
>> Are sorry.  You were talking about the unsigned fixed size integers
>> inside the bignums (what GMP calls the "limbs" IIRC), where I was
>> thinking about the bignums themselves.
>
> One of the key differences between BID and GMP is that the 128-bit
> binary decimal fp is exactly specified, and the 128-bit size if fixed
> and will therefore always fit in two 64-bit (unsigned) regs.
>
> GMPs limbs are by definition the individual (also unsigned) elements of
> variable length arrays.
>

Haven't really used GMP so don't know that much how it works.

I guess I can note that within my compiler, some similar sort of cases
have come up, but is handled in different ways at different levels.

Decided to leave out a bunch of stuff, but in loose summary:
Values less than 64 bits: Generally handled directly.
64-bit data can be expressed directly in ASTs;
Passed as a 64-bit VLI in the RIL3 stage (always signed, *1);
Full-width 64-bit data needs to be escaped in the 3AC's scheme.
In this case, larger values handled with a lookup table.
Values less than 128 bits:
Expressed as attribute pairs at the AST level (AST only does 64b);
Passed as a pair of 64-bit VLIs in the RIL3 stage (always signed);
Handled via a lookup pair in the 3AC backend.
Values more than 128 bits:
In the AST, serialized to an ASCII string (*2);
Also encoded as a string in RIL3;
In 3AC backend, internally stored using a string
But the function calls work using arrays of 64-bit values.

*1:
VLI scheme encodes a number as a variable number of bytes:
0zzzzzzz 00000000..0000007F
10zzzzzz zzzzzzzz 00000080..00003FFF
110zzzzz ... 00004000..001FFFFF
1110zzzz ... 00200000..0FFFFFFF
...
Encoding up to 64 bits at a time.
Sign uses a "zigzag" scheme: 0, -1, 1, -2, 2, -3, 3, ...
Typically used even for unsigned values.

*2:
Numbers are mapped to ASCII with a scheme which maps 64 bits to groups
of 11 ASCII characters, effectively using a vaguely similar scheme to
uuencode or similar.
In this case, groups 6 bits are mapped to '0'(0x30)..'o'(0x6F).

This was preferable over "raw binary" strings mostly because BGBCC deals
with binary string literals by UTF-8 encoding them (actual UTF8 strings
are effectively double-encoded).

Both code complexity and minimization of storage overhead favored this
approach.

Another possibility would have been hexadecimal, except:
Average-case storage for a hex string worse than UTF8'ed binary;
Computational cost of encoding/decoding hex is worse than either.

Base85 would have been more compact, but is also a lot more complicated
and slower to encode/decode.

Although "kinda crap", reusing strings for this allowed avoiding a bunch
of complexity that would have been needed to add a new set of mechanisms.

The large number cases are treated internally like a character encoding.
What type of string is it?
ASCII (Technically UTF8, but encodes raw bytes)
UTF8 (UTF-8, Double-encoded)
UCS2 (Encoded as UTF8 in BGBCC)
UCS4 (Encoded as UTF8 in BGBCC)
Big Integer
_BitInt (Signed and Unsigned)
_Decimal (?)
...

Note that predicates which check in a 3AC "register" is a string-literal
will return false if it is marked as a big-integer literal or similar.

In some places in the compiler, an implicit limit of 2048 bits is
assumed at present for these literals.

Parsing numeric literals depends some on whether a suffix is supplied.
Read token (and suffix, if present);
First try to decode as 128 bits;
This function may now return an error status if "out of range";
If we have a suffix, parse as the expected format for this type;
May truncate values in some cases.
If it was outside the 128-bit range:
Reparse number and convert to string based format;
Use this.
If number needs 128-bit range:
Handle as this.
Else:
Use a normal integer literal (64b or less).

Nevermind if things like inline ASM blobs and similar are also passed
around as string literals.

But, yeah, compiler tech is fun...
....

Re: Extended double precision decimal floating point

<1124831721.672972716.348321.acolvin-efunct.com@news.eternal-september.org>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: acol...@efunct.com (mac)
Newsgroups: comp.arch
Subject: Re: Extended double precision decimal floating point
Date: Sat, 30 Apr 2022 19:45:42 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <1124831721.672972716.348321.acolvin-efunct.com@news.eternal-september.org>
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>
<2022Apr25.082201@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 30 Apr 2022 19:45:42 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="93975b5f2ee12b0ff693b5d05874fc77";
logging-data="10030"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fZuiUfvC0cViLZuWFMzBQ"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:Yj8oc9L4KDW60BcLjNcynx+QpHQ=
sha1:1vCyxB3M4FAtDpKwYVm+IxdSeSA=
 by: mac - Sat, 30 Apr 2022 19:45 UTC

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

Not exactly nobody. Honeywell 6600 (later Honeywell DPS8) had decimal
floating point in the extended instruction set. Binary exponent, though.
Implemented in hardware in 6600, microcode in DPS8. A variant of this
architecture ran Multics.

https://www.multicians.org/AL39.pdf#page19

I assume it was for Cobol, and also for marketing against IBM.

Re: Extended double precision decimal floating point

<2022Apr30.225413@mips.complang.tuwien.ac.at>

 copy mid

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

 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: Sat, 30 Apr 2022 20:54:13 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 17
Message-ID: <2022Apr30.225413@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> <2022Apr25.082201@mips.complang.tuwien.ac.at> <1124831721.672972716.348321.acolvin-efunct.com@news.eternal-september.org>
Injection-Info: reader02.eternal-september.org; posting-host="0a982708a1ecf4caa459b05701c8552a";
logging-data="856"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+YDL6/FOu3TLnUYPrlDLkt"
Cancel-Lock: sha1:43yIm9mTK+jcSqQEJv52SKekk4o=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 30 Apr 2022 20:54 UTC

mac <acolvin@efunct.com> writes:
>> 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,
>
>Not exactly nobody. Honeywell 6600 (later Honeywell DPS8) had decimal
>floating point in the extended instruction set. Binary exponent, though.
>Implemented in hardware in 6600, microcode in DPS8.

Interesting, but I expect that they did not implement IEEE 754 decimal
formats (which AFAIK were only standardized in the 2008 revision). So
the only hardware implementation of that remains IBM's.

- 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

<7755fea5-87eb-4ae8-b10c-ef4a9fa96fc4n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:5f13:0:b0:2f1:f414:e037 with SMTP id x19-20020ac85f13000000b002f1f414e037mr5228313qta.257.1651365242672;
Sat, 30 Apr 2022 17:34:02 -0700 (PDT)
X-Received: by 2002:a05:6870:d254:b0:e9:5d17:9e35 with SMTP id
h20-20020a056870d25400b000e95d179e35mr2247890oac.154.1651365242459; Sat, 30
Apr 2022 17:34:02 -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, 30 Apr 2022 17:34:02 -0700 (PDT)
In-Reply-To: <1124831721.672972716.348321.acolvin-efunct.com@news.eternal-september.org>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:6947:3c86:73e1:a64e;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:6947:3c86:73e1:a64e
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>
<2022Apr25.082201@mips.complang.tuwien.ac.at> <1124831721.672972716.348321.acolvin-efunct.com@news.eternal-september.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7755fea5-87eb-4ae8-b10c-ef4a9fa96fc4n@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Sun, 01 May 2022 00:34:02 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 15
 by: Quadibloc - Sun, 1 May 2022 00:34 UTC

On Saturday, April 30, 2022 at 1:45:45 PM UTC-6, mac wrote:
> > 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,
>
> Not exactly nobody. Honeywell 6600 (later Honeywell DPS8) had decimal
> floating point in the extended instruction set. Binary exponent, though.
> Implemented in hardware in 6600, microcode in DPS8. A variant of this
> architecture ran Multics.

Another example, also predating IBM's modern version of DFP,
is the Wang VS series of computers, which had decimal floating point
based on packed decimal, with the format otherwise the same as the
IBM 360's normal floating-point.

John Savard

Re: Extended double precision decimal floating point

<7ce4b1f2-8924-409f-84c9-775bf39495aan@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:1722:b0:69e:e99a:db06 with SMTP id az34-20020a05620a172200b0069ee99adb06mr4325379qkb.534.1651365778896;
Sat, 30 Apr 2022 17:42:58 -0700 (PDT)
X-Received: by 2002:a05:6808:1446:b0:325:df3c:1072 with SMTP id
x6-20020a056808144600b00325df3c1072mr1396665oiv.103.1651365778669; Sat, 30
Apr 2022 17:42:58 -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, 30 Apr 2022 17:42:58 -0700 (PDT)
In-Reply-To: <7755fea5-87eb-4ae8-b10c-ef4a9fa96fc4n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:6947:3c86:73e1:a64e;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:6947:3c86:73e1:a64e
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>
<2022Apr25.082201@mips.complang.tuwien.ac.at> <1124831721.672972716.348321.acolvin-efunct.com@news.eternal-september.org>
<7755fea5-87eb-4ae8-b10c-ef4a9fa96fc4n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7ce4b1f2-8924-409f-84c9-775bf39495aan@googlegroups.com>
Subject: Re: Extended double precision decimal floating point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Sun, 01 May 2022 00:42:58 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 28
 by: Quadibloc - Sun, 1 May 2022 00:42 UTC

On Saturday, April 30, 2022 at 6:34:04 PM UTC-6, Quadibloc wrote:
> On Saturday, April 30, 2022 at 1:45:45 PM UTC-6, mac wrote:

(quoting Anton Ertl)
> > > 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,

> > Not exactly nobody. Honeywell 6600 (later Honeywell DPS8) had decimal
> > floating point in the extended instruction set. Binary exponent, though.
> > Implemented in hardware in 6600, microcode in DPS8. A variant of this
> > architecture ran Multics.

> Another example, also predating IBM's modern version of DFP,
> is the Wang VS series of computers, which had decimal floating point
> based on packed decimal, with the format otherwise the same as the
> IBM 360's normal floating-point.
>
However, while this shows that he wasn't _quite_ right, it hardly
refutes Anton Ertl's main point. Since instruction sets that include
decimal floating-point as a feature on a computer which does binary
arithmetic (computers like the IBM 7070/7074 which had decimal
floating point in order to _have_ floating point, being entirely decimal
computers, perhaps don't count) are few and far between, the importance
and usefulness of such a feature can well be called into question.
If it were needed, one would expect it to be available on nearly every
computer over a certain size.

John Savard

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor