Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Buy land. They've stopped making it." -- Mark Twain


devel / comp.arch / Re: Upcoming DFP support in clang/LLVM

SubjectAuthor
* Upcoming DFP support in clang/LLVMIvan Godard
+* Re: Upcoming DFP support in clang/LLVMQuadibloc
|`* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| +* Re: Upcoming DFP support in clang/LLVMJohn Levine
| |+* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| ||`* Re: Upcoming DFP support in clang/LLVMJohn Levine
| || +- Re: Upcoming DFP support in clang/LLVMQuadibloc
| || `* Re: Upcoming DFP support in clang/LLVMJohn Dallman
| ||  `* Re: Upcoming DFP support in clang/LLVMBGB
| ||   `* Re: Upcoming DFP support in clang/LLVMJohn Dallman
| ||    `* Re: Upcoming DFP support in clang/LLVMBGB
| ||     +* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| ||     |`* Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| ||     | `* Re: Upcoming DFP support in clang/LLVMTim Rentsch
| ||     |  +- Re: Upcoming DFP support in clang/LLVMMitchAlsup
| ||     |  `* Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| ||     |   `- Re: Upcoming DFP support in clang/LLVMBGB
| ||     `- Re: Upcoming DFP support in clang/LLVMJohn Dallman
| |+- Re: Upcoming DFP support in clang/LLVMThomas Koenig
| |`* Re: Upcoming DFP support in clang/LLVMBGB
| | +- Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| | +* Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | | `* Architecture comparison (was: Upcoming DFP support in clang/LLVM)Anton Ertl
| | | |  `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   +* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Bill Findlay
| | | |   |`* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   | `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |   |  `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   |   +* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Ivan Godard
| | | |   |   |`- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |   |   `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |   |    +- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   |    `* Re: Architecture comparisonTerje Mathisen
| | | |   |     +- Re: Architecture comparisonBGB
| | | |   |     +* Re: Architecture comparisonThomas Koenig
| | | |   |     |`- Re: Architecture comparisonMitchAlsup
| | | |   |     `* Re: Architecture comparisonMichael S
| | | |   |      `* Re: Architecture comparisonMitchAlsup
| | | |   |       +- Re: Architecture comparisonBGB
| | | |   |       `- Re: Architecture comparisonMichael S
| | | |   `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |    `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Quadibloc
| | | |     `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Stephen Fuld
| | | |      `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |       `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Stephen Fuld
| | | |        `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |         +- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)John Dallman
| | | |         `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Robert Swindells
| | | |          `- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Torbjorn Lindgren
| | | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | | `- Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | +* Re: Upcoming DFP support in clang/LLVMStephen Fuld
| | | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | | |`- Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| | | | `* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |  +* Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | | |  |+- Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |  |`- Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| | | |  +- Re: Upcoming DFP support in clang/LLVMrobf...@gmail.com
| | | |  `- Re: Upcoming DFP support in clang/LLVMBGB
| | | +- Re: Graphics in the old days, wasUpcoming DFP support in clang/LLVMJohn Levine
| | | `- Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | |`* Re: Upcoming DFP support in clang/LLVMBill Findlay
| | | +- Re: Upcoming DFP support in clang/LLVMIvan Godard
| | | `* Re: Upcoming DFP support in clang/LLVMBrian G. Lucas
| | |  `- Re: Upcoming DFP support in clang/LLVMBill Findlay
| | +- Re: Upcoming DFP support in clang/LLVMStephen Fuld
| | +* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| | |`* Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | | `* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| | |  +* Re: Fortran archaeology, Upcoming DFP support in clang/LLVMJohn Levine
| | |  |`* Re: Fortran archaeology, Upcoming DFP support in clang/LLVMMitchAlsup
| | |  | `* Re: Fortran archaeology, Upcoming DFP support in clang/LLVMThomas Koenig
| | |  |  `- Re: Fortran archaeology, Upcoming DFP support in clang/LLVMMitchAlsup
| | |  `- Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |  `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBGB
| |   +* Re: tiny little computers, was Upcoming DFP support in clang/LLVMaph
| |   |`* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBGB
| |   | `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |   |  +* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBill Findlay
| |   |  |`* Re: tiny little computers, was Upcoming DFP support in clang/LLVMIvan Godard
| |   |  | `- Re: tiny little pages, was Upcoming DFP support in clang/LLVMJohn Levine
| |   |  +- Re: tiny little computers, was Upcoming DFP support in clang/LLVMBGB
| |   |  +* Re: tiny little computers, was Upcoming DFP support in clang/LLVMMitchAlsup
| |   |  |`- Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |   |  `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMEricP
| |   |   `- Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |   +- Re: tiny little computers, was Upcoming DFP support in clang/LLVMRobert Swindells
| |   `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMEricP
| |    `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBill Findlay
| |     `- Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| +- Re: Upcoming DFP support in clang/LLVMGuillaume
| `* Re: Upcoming DFP support in clang/LLVMThomas Koenig
|  `* Re: Upcoming DFP support in clang/LLVMThomas Koenig
`* Re: Upcoming DFP support in clang/LLVMMichael S

Pages:12345
Upcoming DFP support in clang/LLVM

<t4peor$cch$1@dont-email.me>

 copy mid

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

 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: Upcoming DFP support in clang/LLVM
Date: Mon, 2 May 2022 13:26:05 -0700
Organization: A noiseless patient Spider
Lines: 1
Message-ID: <t4peor$cch$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 2 May 2022 20:26:03 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="3950cbe5d643e25fe0aae9fe2035281e";
logging-data="12689"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+PgfdSiNg3bs4Ke4Zl7Ddp"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:bGH45PlhGqM4xzSORh5NCrEuZhg=
Content-Language: en-US
 by: Ivan Godard - Mon, 2 May 2022 20:26 UTC

https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152

Re: Upcoming DFP support in clang/LLVM

<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:3189:b0:69f:421e:ba00 with SMTP id bi9-20020a05620a318900b0069f421eba00mr10261064qkb.485.1651529354854;
Mon, 02 May 2022 15:09:14 -0700 (PDT)
X-Received: by 2002:a05:6870:b68d:b0:de:9da7:9615 with SMTP id
cy13-20020a056870b68d00b000de9da79615mr581946oab.117.1651529354585; Mon, 02
May 2022 15:09:14 -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: Mon, 2 May 2022 15:09:14 -0700 (PDT)
In-Reply-To: <t4peor$cch$1@dont-email.me>
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: <t4peor$cch$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Mon, 02 May 2022 22:09:14 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 8
 by: Quadibloc - Mon, 2 May 2022 22:09 UTC

On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
> https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152

According to that, the project has just begun.

It is reasonable that this project _should_ begin, given that the current C standard has
provision for DFP, and there are some machines out there with DFP support.

John Savard

Re: Upcoming DFP support in clang/LLVM

<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:1c83:b0:443:6749:51f8 with SMTP id ib3-20020a0562141c8300b00443674951f8mr11867478qvb.74.1651540628462;
Mon, 02 May 2022 18:17:08 -0700 (PDT)
X-Received: by 2002:a05:6870:b383:b0:e9:2fea:2148 with SMTP id
w3-20020a056870b38300b000e92fea2148mr826985oap.103.1651540628244; Mon, 02 May
2022 18:17:08 -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: Mon, 2 May 2022 18:17:08 -0700 (PDT)
In-Reply-To: <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b8e9:1ed6:4f6c:62c1;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b8e9:1ed6:4f6c:62c1
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 03 May 2022 01:17:08 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 11
 by: MitchAlsup - Tue, 3 May 2022 01:17 UTC

On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
> > https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
>
> According to that, the project has just begun.
>
> It is reasonable that this project _should_ begin, given that the current C standard has
> provision for DFP, and there are some machines out there with DFP support.
<
Representing 0.000,1% of chips containing CPUs; sold annually.
>
> John Savard

Re: Upcoming DFP support in clang/LLVM

<t4q2cn$l82$1@gal.iecc.com>

 copy mid

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

 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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 02:00:55 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t4q2cn$l82$1@gal.iecc.com>
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
Injection-Date: Tue, 3 May 2022 02:00:55 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="21762"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Tue, 3 May 2022 02:00 UTC

According to MitchAlsup <MitchAlsup@aol.com>:
>On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
>> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
>> > https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
>>
>> According to that, the project has just begun.
>>
>> It is reasonable that this project _should_ begin, given that the current C standard has
>> provision for DFP, and there are some machines out there with DFP support.
><
>Representing 0.000,1% of chips containing CPUs; sold annually.

I was wondering who's funding this. Who thinks it's worth the effort?

R's,
John
--
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: Upcoming DFP support in clang/LLVM

<301dfd7b-e791-41a1-a14c-148343531653n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:5cac:0:b0:45a:8e5c:677 with SMTP id q12-20020ad45cac000000b0045a8e5c0677mr4957129qvh.125.1651543724749;
Mon, 02 May 2022 19:08:44 -0700 (PDT)
X-Received: by 2002:a54:4f83:0:b0:324:f58f:4b95 with SMTP id
g3-20020a544f83000000b00324f58f4b95mr934009oiy.4.1651543722934; Mon, 02 May
2022 19:08:42 -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: Mon, 2 May 2022 19:08:42 -0700 (PDT)
In-Reply-To: <t4q2cn$l82$1@gal.iecc.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b8e9:1ed6:4f6c:62c1;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b8e9:1ed6:4f6c:62c1
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <301dfd7b-e791-41a1-a14c-148343531653n@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 03 May 2022 02:08:44 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 21
 by: MitchAlsup - Tue, 3 May 2022 02:08 UTC

On Monday, May 2, 2022 at 9:00:58 PM UTC-5, John Levine wrote:
> According to MitchAlsup <Mitch...@aol.com>:
> >On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
> >> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
> >> > https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
> >>
> >> According to that, the project has just begun.
> >>
> >> It is reasonable that this project _should_ begin, given that the current C standard has
> >> provision for DFP, and there are some machines out there with DFP support.
> ><
> >Representing 0.000,1% of chips containing CPUs; sold annually.
> I was wondering who's funding this. Who thinks it's worth the effort?
<
Probably banks--COBOLholics.
>
> R's,
> John
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Re: Upcoming DFP support in clang/LLVM

<t4q492$1f2k$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!PIYJZAYRkS4/7zt+lHFyRg.user.46.165.242.75.POSTED!not-for-mail
From: mess...@bottle.org (Guillaume)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 04:33:06 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t4q492$1f2k$1@gioia.aioe.org>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="48212"; posting-host="PIYJZAYRkS4/7zt+lHFyRg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.1
Content-Language: fr
X-Notice: Filtered by postfilter v. 0.9.2
 by: Guillaume - Tue, 3 May 2022 02:33 UTC

Le 03/05/2022 à 03:17, MitchAlsup a écrit :
> On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
>> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
>>> https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
>>
>> According to that, the project has just begun.
>>
>> It is reasonable that this project _should_ begin, given that the current C standard has
>> provision for DFP, and there are some machines out there with DFP support.
> <
> Representing 0.000,1% of chips containing CPUs; sold annually.

Yes, but you'll be able to represent this fraction exactly using DFP. =)

Re: Upcoming DFP support in clang/LLVM

<t4q595$vv2$1@gal.iecc.com>

 copy mid

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

 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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 02:50:13 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t4q595$vv2$1@gal.iecc.com>
References: <t4peor$cch$1@dont-email.me> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com> <301dfd7b-e791-41a1-a14c-148343531653n@googlegroups.com>
Injection-Date: Tue, 3 May 2022 02:50:13 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="32738"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <t4peor$cch$1@dont-email.me> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com> <301dfd7b-e791-41a1-a14c-148343531653n@googlegroups.com>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Tue, 3 May 2022 02:50 UTC

It appears that MitchAlsup <MitchAlsup@aol.com> said:
>> >Representing 0.000,1% of chips containing CPUs; sold annually.
>> I was wondering who's funding this. Who thinks it's worth the effort?
><
>Probably banks--COBOLholics.

Maybe, but why clang? There's already DFP support in the IBM compilers
people are likely to use on machines with DFP hardware and in gcc.

--
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: Upcoming DFP support in clang/LLVM

<54499315-6818-41b6-9894-081232b97520n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:7c8:0:b0:69f:c5f8:85a2 with SMTP id 191-20020a3707c8000000b0069fc5f885a2mr9565053qkh.662.1651548184724;
Mon, 02 May 2022 20:23:04 -0700 (PDT)
X-Received: by 2002:a05:6808:c2:b0:325:eb71:7266 with SMTP id
t2-20020a05680800c200b00325eb717266mr1058951oic.269.1651548184503; Mon, 02
May 2022 20:23:04 -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: Mon, 2 May 2022 20:23:04 -0700 (PDT)
In-Reply-To: <t4q595$vv2$1@gal.iecc.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: <t4peor$cch$1@dont-email.me> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <301dfd7b-e791-41a1-a14c-148343531653n@googlegroups.com>
<t4q595$vv2$1@gal.iecc.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <54499315-6818-41b6-9894-081232b97520n@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Tue, 03 May 2022 03:23:04 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 8
 by: Quadibloc - Tue, 3 May 2022 03:23 UTC

On Monday, May 2, 2022 at 8:50:16 PM UTC-6, John Levine wrote:

> Maybe, but why clang? There's already DFP support in the IBM compilers
> people are likely to use on machines with DFP hardware and in gcc.

Well, if GCC has it, clearly clang has to have it too! Otherwise, clang would
fall behind, and no longer be an active competitor to GCC!

John Savard

Re: Upcoming DFP support in clang/LLVM

<t4qe9n$vim$1@newsreader4.netcologne.de>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 05:24:07 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t4qe9n$vim$1@newsreader4.netcologne.de>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
Injection-Date: Tue, 3 May 2022 05:24:07 -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="32342"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Tue, 3 May 2022 05:24 UTC

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
>> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
>> > https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
>>
>> According to that, the project has just begun.
>>
>> It is reasonable that this project _should_ begin, given that the current C standard has
>> provision for DFP, and there are some machines out there with DFP support.
><
> Representing 0.000,1% of chips containing CPUs; sold annually.

Nice floating point format :-)

Are there any sources for the number of POWER processors sold
these days?

Re: Upcoming DFP support in clang/LLVM

<t4qej4$vim$2@newsreader4.netcologne.de>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 05:29:08 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t4qej4$vim$2@newsreader4.netcologne.de>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com>
Injection-Date: Tue, 3 May 2022 05:29:08 -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="32342"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Tue, 3 May 2022 05:29 UTC

John Levine <johnl@taugh.com> schrieb:
> According to MitchAlsup <MitchAlsup@aol.com>:
>>On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
>>> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
>>> > https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
>>>
>>> According to that, the project has just begun.
>>>
>>> It is reasonable that this project _should_ begin, given that the current C standard has
>>> provision for DFP, and there are some machines out there with DFP support.
>><
>>Representing 0.000,1% of chips containing CPUs; sold annually.
>
> I was wondering who's funding this. Who thinks it's worth the effort?

IBM is funding a lot of open source compiler development.
In software especially, a little money (by corporate standards)
can go a long way in getting an excellent result.

This is why POWER is a primary platform for gcc, for example.
(and it sure doesn't hurt that some of gcc's primary developers
work for RedHat, which IBM bought).

Re: Upcoming DFP support in clang/LLVM

<memo.20220503073912.8344E@jgd.cix.co.uk>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.neodome.net!news.mixmin.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jgd...@cix.co.uk (John Dallman)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 07:39 +0100 (BST)
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <memo.20220503073912.8344E@jgd.cix.co.uk>
References: <t4q595$vv2$1@gal.iecc.com>
Reply-To: jgd@cix.co.uk
Injection-Info: reader02.eternal-september.org; posting-host="33f86f8a33c117f4c692308f3a4267e9";
logging-data="16876"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Xv5NTFVO0sFKkdp+75a11vk+7lPGDf/Y="
Cancel-Lock: sha1:GhpZB7e2YXIpbRJ3jH1bK24uIbA=
 by: John Dallman - Tue, 3 May 2022 06:39 UTC

In article <t4q595$vv2$1@gal.iecc.com>, johnl@taugh.com (John Levine)
wrote:

> Maybe, but why clang? There's already DFP support in the IBM
> compilers people are likely to use on machines with DFP hardware
> and in gcc.

IBM is abandoning its own C and C++ compilers and replacing them with
Clang. Presumably Clang rather than GCC because of the more permissive
license for vendor-specific add-ons.

The IBM XL family of compilers was stopped at C++98 for quite a long time,
seemingly because they didn't want to pay the development costs for C++11
and later standards. IBM seem to have been having an internal argument
about this, because of their belief that the XL back-end optimised as
well for POWER as was physically possible, but the Clang advocates have
won that battle.

The only compilers that seem to be trying to keep up with the rapid
evolution of the C++ standard (C++11, C++14, C++17, and C++20, with C++23
and C++26 under development) are MSVC, GCC and Clang.

John

Re: Upcoming DFP support in clang/LLVM

<t4qlfi$42b$1@dont-email.me>

 copy mid

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

 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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 02:26:33 -0500
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <t4qlfi$42b$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 3 May 2022 07:26:42 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="d34dae49020eda54527366dd36476a99";
logging-data="4171"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19UHFMSFJ+PVnPEAyjnBGJc"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:XnFtNTTQjM8jZYOOAVpApZL6rmY=
In-Reply-To: <t4q2cn$l82$1@gal.iecc.com>
Content-Language: en-US
 by: BGB - Tue, 3 May 2022 07:26 UTC

On 5/2/2022 9:00 PM, John Levine wrote:
> According to MitchAlsup <MitchAlsup@aol.com>:
>> On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
>>> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
>>>> https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
>>>
>>> According to that, the project has just begun.
>>>
>>> It is reasonable that this project _should_ begin, given that the current C standard has
>>> provision for DFP, and there are some machines out there with DFP support.
>> <
>> Representing 0.000,1% of chips containing CPUs; sold annually.
>
> I was wondering who's funding this. Who thinks it's worth the effort?
>

Not every compiler feature necessarily needs to be present in hardware.

For example, C was/is often compiled to machines which where only a
select few arithmetic operators could actually be implemented in
hardware, and pretty much everything else is runtime calls.

Say, for example, if one can build C for a machine which lacks ISA level
support for things like integer multiply or divide (and also does
floating point in software, ...), it doesn't seem like too much of a
stretch to support decimal floating point in software and then not
bother with hardware support.

Sometimes, it is merely sufficient if built-in compiler support can be
better than having user-code implement the feature by writing it in C,
while is (frequently) still the case.

This would include things like types larger than those which exist
within the base ISA, operators which do not exist in the ISA and need to
be faked in software, ...

I was originally going to use C on 70s era hardware as an example, but
then went and looked it up, and realized that the PDP-11 and VAX were in
many regards more comparable (in terms of feature-set) to a 90s desktop
PC than they were to computers built around the 6502 or 8080 and similar
(despite the 6502 and 8080 being newer than the VAX).

Well, that and it answers another mystery: "How could you have fit Unix
onto computers with only a few K of RAM?..." Apparently, they didn't,
they (somehow) had access to machines in the 70s with MB of RAM.

Well, along with having integer multiply/divide/... in hardware.

I guess this explains why breaking 1 DMIPS/MHz is actually a challenge
rather than being "dead easy", and why some 8-bit era processors
seemingly only pulled off ~ 0.05 DMIPS/MHz and similar.

I guess this leaves things like the 80s era PCs and similar as an
outlier?...

Strangely, it seems even very early vacuum-tube era computers were a lot
wider (in terms of word-size, ...) than this era of computers.

Like, despite dealing with relays or vacuum tubes, they would still much
rather go with 24 or 36 bits than try to do calculations using 8 bits or
similar?...

Then again, there is a problem I have noted in my own compiler:
Things like C library support for a feature ("just in case") it is used,
tends to create a dependency on the feature in question (causing it to
be linked in, even if not actually needed by the program).

Say, the application doesn't itself use __int128, __float128, ... but
ends up needing to drag in runtime support because they are still needed
to be able to "printf()" these types (and by extension, any program
which calls "printf()", which is pretty much everything, ends up needing
to pull in the runtime support code for these features).

Otherwise, one would need to build alternate versions of the C library,
and then link in a version specifically for the feature-set used by the
application (assuming the use of a static-linked C library).

Also assuming a lack of more heavy-handed trickery, like the compiler
trying to specialize which "printf()" version is used based on the
contents of the format strings or similar.

Eg:
No arguments, transform into "puts()"
Only primitive specifiers, use a "lite" version
Say, like version only does "%d", "%u", "%X", "%s", ...
But, not any more advanced types or formatting.
...

This can then omits a version which supports "__int128" and "__float128"
and similar if these never appear in any of the format strings used by
the program. Though, this optimization is trivially defeated if at any
point the application calls "printf()" with a format string that is not
a string literal.

Also potentially adds the bulk of needing to link in multiple versions
of printf (potentially making the situation worse than had it only used
a single "do everything" version).

....

Re: Upcoming DFP support in clang/LLVM

<t4qm5s$8rv$1@dont-email.me>

 copy mid

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

 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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 02:38:27 -0500
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <t4qm5s$8rv$1@dont-email.me>
References: <t4q595$vv2$1@gal.iecc.com>
<memo.20220503073912.8344E@jgd.cix.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 3 May 2022 07:38:37 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="d34dae49020eda54527366dd36476a99";
logging-data="9087"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/cHd7zDlR8hIddlzJoa/HK"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:eaeJSrbuytyOk0S/ib4RKhS8YMM=
In-Reply-To: <memo.20220503073912.8344E@jgd.cix.co.uk>
Content-Language: en-US
 by: BGB - Tue, 3 May 2022 07:38 UTC

On 5/3/2022 1:38 AM, John Dallman wrote:
> In article <t4q595$vv2$1@gal.iecc.com>, johnl@taugh.com (John Levine)
> wrote:
>
>> Maybe, but why clang? There's already DFP support in the IBM
>> compilers people are likely to use on machines with DFP hardware
>> and in gcc.
>
> IBM is abandoning its own C and C++ compilers and replacing them with
> Clang. Presumably Clang rather than GCC because of the more permissive
> license for vendor-specific add-ons.
>
> The IBM XL family of compilers was stopped at C++98 for quite a long time,
> seemingly because they didn't want to pay the development costs for C++11
> and later standards. IBM seem to have been having an internal argument
> about this, because of their belief that the XL back-end optimised as
> well for POWER as was physically possible, but the Clang advocates have
> won that battle.
>
> The only compilers that seem to be trying to keep up with the rapid
> evolution of the C++ standard (C++11, C++14, C++17, and C++20, with C++23
> and C++26 under development) are MSVC, GCC and Clang.
>

For a small team or single-developer C compiler, trying to play catch-up
and implement all this stuff is basically no-go.

It is more viable, say:
Mostly or exclusively focus on C;
Cherry pick those features which seem useful, and ignore everything else.

This is mostly at-odds with the "everything and the kitchen sink"
approach common in C++ land, where people are chasing after the newest
language features is some attempt to be "modern".

For the most part, C still tends to look a lot like C90, with the
occasional random feature from a newer version of the standard, or the
use of optional compiler-specific extensions.

Say, one has a compiler which has things like 'u8' string literals, but
lacks things like _Generic or similar because it is hard to imagine
enough of a use-case to make a strong case for implementing them.

Even then, there are still a lot of edge cases that may pop up and need
to be dealt with.

> John

Re: Upcoming DFP support in clang/LLVM

<t4qmuc$1g7k$1@gioia.aioe.org>

 copy mid

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

 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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 09:51:39 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t4qmuc$1g7k$1@gioia.aioe.org>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$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="49396"; 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 - Tue, 3 May 2022 07:51 UTC

BGB wrote:
> On 5/2/2022 9:00 PM, John Levine wrote:
>> According to MitchAlsup  <MitchAlsup@aol.com>:
>>> On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
>>>> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
>>>>> https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
>>>>>
>>>>
>>>> According to that, the project has just begun.
>>>>
>>>> It is reasonable that this project _should_ begin, given that the
>>>> current C standard has
>>>> provision for DFP, and there are some machines out there with DFP
>>>> support.
>>> <
>>> Representing 0.000,1% of chips containing CPUs; sold annually.
>>
>> I was wondering who's funding this.  Who thinks it's worth the effort?
>>
>
>
> Not every compiler feature necessarily needs to be present in hardware.
>
> For example, C was/is often compiled to machines which where only a
> select few arithmetic operators could actually be implemented in
> hardware, and pretty much everything else is runtime calls.

I read the proposal, due to the need for cross-compiling and having
multiple targets, clang will be forced to include code (software
emaulation) for both BID and DPD encodings, as well as conversions
between them.

This will probably lead to some people like/similar to Michael S (and
possibly myself) becoming interested in optimizing said libraries.

At that point DPF support can become a given, something developers can
expect to be there even if performance might be 1 to 2 orders of
magnitude worse than the comparable binary FP operations.

Terje

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

Re: Upcoming DFP support in clang/LLVM

<t4qsuk$77p$1@newsreader4.netcologne.de>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 09:34:12 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t4qsuk$77p$1@newsreader4.netcologne.de>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
Injection-Date: Tue, 3 May 2022 09:34:12 -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="7417"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Tue, 3 May 2022 09:34 UTC

BGB <cr88192@gmail.com> schrieb:

> Well, that and it answers another mystery: "How could you have fit Unix
> onto computers with only a few K of RAM?..." Apparently, they didn't,
> they (somehow) had access to machines in the 70s with MB of RAM.

This turns out not to be the case.

The PDP-11 they started serious UNIX development on had 24 kB of
memory and a half-megabyte disk.

Source: UNIX: A History and a Memoir, Brian Kernighan, page 52.

Re: Upcoming DFP support in clang/LLVM

<4dc25465-51ff-45c5-b369-54fb38a27653n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1301:b0:2f3:af1d:aa57 with SMTP id v1-20020a05622a130100b002f3af1daa57mr1119312qtk.257.1651570607146;
Tue, 03 May 2022 02:36:47 -0700 (PDT)
X-Received: by 2002:a05:6808:577:b0:325:8089:eb8b with SMTP id
j23-20020a056808057700b003258089eb8bmr1416958oig.126.1651570606891; Tue, 03
May 2022 02:36:46 -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: Tue, 3 May 2022 02:36:46 -0700 (PDT)
In-Reply-To: <t4peor$cch$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=199.203.251.52; posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 199.203.251.52
References: <t4peor$cch$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4dc25465-51ff-45c5-b369-54fb38a27653n@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: already5...@yahoo.com (Michael S)
Injection-Date: Tue, 03 May 2022 09:36:47 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 20
 by: Michael S - Tue, 3 May 2022 09:36 UTC

On Monday, May 2, 2022 at 11:26:06 PM UTC+3, Ivan Godard wrote:
> https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152

What about quad-precision binary floating point?
Right now, it seems that on x64 Linux __float128 is supported by compiler. However I was unable to
figure out whether run-time support library is provided by LLVM or compiler relies on system-supplied
RTL for actual work. Also, clang does not appear to supply <quadmath.h> header of its own.

On x64 Windows (MSYS2) situation is much worse - clang compiler pretends to support __float128, but
does not understand the ABI.

On aarch64 Linux, it seems there is no support at all, neither as __float128 nor as _Float128.
I'd dare to say that it's a little better than x64 Window (at least, not misleading), but hardly satisfactory.

POWER64LE - the same as aarch64.

RISC V (both 32 bits and 64 bits) - the same as aarch64.

Above I intentionally listed only those targets on which gcc support either __float128 or _Float128 or both.

Re: Upcoming DFP support in clang/LLVM

<bd93e4fa-96ac-4063-ae49-859df730c226n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:15d1:b0:2f3:4dad:9f4 with SMTP id d17-20020a05622a15d100b002f34dad09f4mr14114064qty.287.1651574197417;
Tue, 03 May 2022 03:36:37 -0700 (PDT)
X-Received: by 2002:a05:6830:901:b0:606:2109:714f with SMTP id
v1-20020a056830090100b006062109714fmr2674236ott.58.1651574196848; Tue, 03 May
2022 03:36:36 -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: Tue, 3 May 2022 03:36:36 -0700 (PDT)
In-Reply-To: <t4qlfi$42b$1@dont-email.me>
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: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <bd93e4fa-96ac-4063-ae49-859df730c226n@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Tue, 03 May 2022 10:36:37 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 24
 by: Quadibloc - Tue, 3 May 2022 10:36 UTC

On Tuesday, May 3, 2022 at 1:26:46 AM UTC-6, BGB wrote:

> Well, that and it answers another mystery: "How could you have fit Unix
> onto computers with only a few K of RAM?..." Apparently, they didn't,
> they (somehow) had access to machines in the 70s with MB of RAM.

Did such machines exist?

Well, you could get a IBM 360/195 with up to 2 MB of RAM. And even
up to 16 MB of RAM if you accepted the special slow core.

If we discount the PDP-7 on which Unix was originally developed, however,
on the basis that the Unix that ran on it did not have all the features, and so
we can just look at the PDP-11.

Although the PDP-11/45 was a fairly high-end PDP-11, it could only be
expanded to 32 K words of memory at most, filling the 64 K byte standard
address space.

The PDP-11/70, however, did have a memory management unit that
let it have up to 4 megabytes of physical memory, even though the
address space was still 64 K. But that was only from the latter half
of the 1970s.

John Savard

Re: Upcoming DFP support in clang/LLVM

<t4rbre$vv0$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 06:48:27 -0700
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <t4rbre$vv0$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 3 May 2022 13:48:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="e377a60e020c2192fd3a280d20aaa417";
logging-data="32736"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18/nkLsqUbvQXVflYJ/T5Jy8BY/OjO577Y="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.1
Cancel-Lock: sha1:IK3Rk6RmGSP2VDxtyHLTxjJfYTY=
In-Reply-To: <t4qlfi$42b$1@dont-email.me>
Content-Language: en-US
 by: Stephen Fuld - Tue, 3 May 2022 13:48 UTC

On 5/3/2022 12:26 AM, BGB wrote:

snip

> Strangely, it seems even very early vacuum-tube era computers were a lot
> wider (in terms of word-size, ...) than this era of computers.
>
> Like, despite dealing with relays or vacuum tubes, they would still much
> rather go with 24 or 36 bits than try to do calculations using 8 bits or
> similar?...

Not strange at all once you understand the history. The 8 bit "byte"
was "invented" by IBM in the early 1960s as part of the S/360
development. Even then, there was disagreement within IBM over how many
bits to use for a character.

Prior to that, virtually all computers used 6 bits per character (albeit
with different encodings). The business oriented computers tended to
use variable length character strings, controlled by special characters
such as "word marks" or "record marks". For the scientific ones, some
were decimal, i.e. ten characters per word, but many, by various
vendors, used 36 bits or 6 characters per word. (Of course, CDC used ten
6 bit characters per word.) I vaguely remember there was some US Navy
requirement for the Univac 1103 for floating point precision that
essentially required 36 bits - 32 wouldn't allow enough digits of precision.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Upcoming DFP support in clang/LLVM

<12d8d684-714c-47ff-ae28-79897a5bbbddn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:2f04:0:b0:663:397d:7051 with SMTP id v4-20020a372f04000000b00663397d7051mr13090354qkh.333.1651598967046;
Tue, 03 May 2022 10:29:27 -0700 (PDT)
X-Received: by 2002:a4a:621e:0:b0:35e:950e:6be8 with SMTP id
x30-20020a4a621e000000b0035e950e6be8mr6027509ooc.41.1651598966790; Tue, 03
May 2022 10:29:26 -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: Tue, 3 May 2022 10:29:26 -0700 (PDT)
In-Reply-To: <t4qlfi$42b$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:8c09:3361:4dfd:14be;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:8c09:3361:4dfd:14be
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <12d8d684-714c-47ff-ae28-79897a5bbbddn@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 03 May 2022 17:29:27 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 112
 by: MitchAlsup - Tue, 3 May 2022 17:29 UTC

On Tuesday, May 3, 2022 at 2:26:46 AM UTC-5, BGB wrote:
> On 5/2/2022 9:00 PM, John Levine wrote:
> > According to MitchAlsup <Mitch...@aol.com>:
> >> On Monday, May 2, 2022 at 5:09:16 PM UTC-5, Quadibloc wrote:
> >>> On Monday, May 2, 2022 at 2:26:06 PM UTC-6, Ivan Godard wrote:
> >>>> https://discourse.llvm.org/t/rfc-decimal-floating-point-support-iso-iec-ts-18661-2-and-c23/62152
> >>>
> >>> According to that, the project has just begun.
> >>>
> >>> It is reasonable that this project _should_ begin, given that the current C standard has
> >>> provision for DFP, and there are some machines out there with DFP support.
> >> <
> >> Representing 0.000,1% of chips containing CPUs; sold annually.
> >
> > I was wondering who's funding this. Who thinks it's worth the effort?
> >
> Not every compiler feature necessarily needs to be present in hardware.
>
> For example, C was/is often compiled to machines which where only a
> select few arithmetic operators could actually be implemented in
> hardware, and pretty much everything else is runtime calls.
>
> Say, for example, if one can build C for a machine which lacks ISA level
> support for things like integer multiply or divide (and also does
> floating point in software, ...), it doesn't seem like too much of a
> stretch to support decimal floating point in software and then not
> bother with hardware support.
>
>
> Sometimes, it is merely sufficient if built-in compiler support can be
> better than having user-code implement the feature by writing it in C,
> while is (frequently) still the case.
>
> This would include things like types larger than those which exist
> within the base ISA, operators which do not exist in the ISA and need to
> be faked in software, ...
>
>
>
> I was originally going to use C on 70s era hardware as an example, but
> then went and looked it up, and realized that the PDP-11 and VAX were in
> many regards more comparable (in terms of feature-set) to a 90s desktop
> PC than they were to computers built around the 6502 or 8080 and similar
> (despite the 6502 and 8080 being newer than the VAX).
>
> Well, that and it answers another mystery: "How could you have fit Unix
> onto computers with only a few K of RAM?..." Apparently, they didn't,
> they (somehow) had access to machines in the 70s with MB of RAM.
>
> Well, along with having integer multiply/divide/... in hardware.
>
> I guess this explains why breaking 1 DMIPS/MHz is actually a challenge
> rather than being "dead easy", and why some 8-bit era processors
> seemingly only pulled off ~ 0.05 DMIPS/MHz and similar.
>
>
> I guess this leaves things like the 80s era PCs and similar as an
> outlier?...
>
> Strangely, it seems even very early vacuum-tube era computers were a lot
> wider (in terms of word-size, ...) than this era of computers.
>
> Like, despite dealing with relays or vacuum tubes, they would still much
> rather go with 24 or 36 bits than try to do calculations using 8 bits or
> similar?...
>
>
>
> Then again, there is a problem I have noted in my own compiler:
> Things like C library support for a feature ("just in case") it is used,
> tends to create a dependency on the feature in question (causing it to
> be linked in, even if not actually needed by the program).
>
> Say, the application doesn't itself use __int128, __float128, ... but
> ends up needing to drag in runtime support because they are still needed
> to be able to "printf()" these types (and by extension, any program
> which calls "printf()", which is pretty much everything, ends up needing
> to pull in the runtime support code for these features).
<
in 1982 I was on a project that built a FORTRAN runtime library. We built
the WRITE routines so you only pulled in the data formatters you actually
used, not the entire suite of potentials.
<
Computers are more flexible today, why can't we just pull in the ones
being used and not every-friggen-thing ?
>
> Otherwise, one would need to build alternate versions of the C library,
> and then link in a version specifically for the feature-set used by the
> application (assuming the use of a static-linked C library).
>
> Also assuming a lack of more heavy-handed trickery, like the compiler
> trying to specialize which "printf()" version is used based on the
> contents of the format strings or similar.
>
> Eg:
> No arguments, transform into "puts()"
> Only primitive specifiers, use a "lite" version
> Say, like version only does "%d", "%u", "%X", "%s", ...
> But, not any more advanced types or formatting.
> ...
>
> This can then omits a version which supports "__int128" and "__float128"
> and similar if these never appear in any of the format strings used by
> the program. Though, this optimization is trivially defeated if at any
> point the application calls "printf()" with a format string that is not
> a string literal.
>
> Also potentially adds the bulk of needing to link in multiple versions
> of printf (potentially making the situation worse than had it only used
> a single "do everything" version).
>
>
> ...

Re: Upcoming DFP support in clang/LLVM

<memo.20220503192241.8344H@jgd.cix.co.uk>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jgd...@cix.co.uk (John Dallman)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 19:22 +0100 (BST)
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <memo.20220503192241.8344H@jgd.cix.co.uk>
References: <t4qm5s$8rv$1@dont-email.me>
Reply-To: jgd@cix.co.uk
Injection-Info: reader02.eternal-september.org; posting-host="33f86f8a33c117f4c692308f3a4267e9";
logging-data="5089"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18IaNlXKLOBDDdGtgFzOJKTOOMJrAVA4ao="
Cancel-Lock: sha1:W20uGf01UUi7DC4SubayTAbKLjk=
 by: John Dallman - Tue, 3 May 2022 18:22 UTC

In article <t4qm5s$8rv$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:

> This is mostly at-odds with the "everything and the kitchen sink"
> approach common in C++ land, where people are chasing after the
> newest language features is some attempt to be "modern".

My employers have various teams that get bees in their bonnets about C++
features, though some teams definitely do this more than others. There's
enough code shared between different products that it's worth
coordinating company-wide.

My conclusion has been that you need to stay about one version of the C++
standard behind the bleeding age, given that it takes a while for the
standards to get implemented, and then there are product release cycles
to accommodate.

John

Re: Upcoming DFP support in clang/LLVM

<t4s130$p3o$1@newsreader4.netcologne.de>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 19:50:56 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t4s130$p3o$1@newsreader4.netcologne.de>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<12d8d684-714c-47ff-ae28-79897a5bbbddn@googlegroups.com>
Injection-Date: Tue, 3 May 2022 19:50:56 -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="25720"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Tue, 3 May 2022 19:50 UTC

MitchAlsup <MitchAlsup@aol.com> schrieb:

> in 1982 I was on a project that built a FORTRAN runtime library. We built
> the WRITE routines so you only pulled in the data formatters you actually
> used, not the entire suite of potentials.

How did you deal with formats created at run-time?

> Computers are more flexible today, why can't we just pull in the ones
> being used and not every-friggen-thing ?

Shared libraries. You can see how well they work from the
proliferation of dockers, snaps, and whatnot.

Re: Upcoming DFP support in clang/LLVM

<67754cbf-fcbf-4ce2-887d-6c6b55087427n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:1767:b0:456:f39:4cbb with SMTP id et7-20020a056214176700b004560f394cbbmr14943008qvb.37.1651610037824;
Tue, 03 May 2022 13:33:57 -0700 (PDT)
X-Received: by 2002:a05:6870:969e:b0:ed:9e77:8eba with SMTP id
o30-20020a056870969e00b000ed9e778ebamr2627253oaq.269.1651610037583; Tue, 03
May 2022 13:33:57 -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: Tue, 3 May 2022 13:33:57 -0700 (PDT)
In-Reply-To: <t4s130$p3o$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:f44f:e17f:a77b:7259;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:f44f:e17f:a77b:7259
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <12d8d684-714c-47ff-ae28-79897a5bbbddn@googlegroups.com>
<t4s130$p3o$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <67754cbf-fcbf-4ce2-887d-6c6b55087427n@googlegroups.com>
Subject: Re: Upcoming DFP support in clang/LLVM
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 03 May 2022 20:33:57 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 19
 by: MitchAlsup - Tue, 3 May 2022 20:33 UTC

On Tuesday, May 3, 2022 at 2:50:59 PM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > in 1982 I was on a project that built a FORTRAN runtime library. We built
> > the WRITE routines so you only pulled in the data formatters you actually
> > used, not the entire suite of potentials.
> How did you deal with formats created at run-time?
<
The FORTRAN of that era did not have those. I don't know what the modern
FORTRANs have. But out (S.E.L.) FORTRAN had a format compiler that read
character strings and emitted a sequence of code that performed formatting
chores (much of it subroutine calls). Only the subroutines actually called got
put in the linked library. The rest could get dynamically linked on demand.
<
> > Computers are more flexible today, why can't we just pull in the ones
> > being used and not every-friggen-thing ?
<
> Shared libraries. You can see how well they work from the
> proliferation of dockers, snaps, and whatnot.
<
Abuse of the concept of shared libraries is more like it.

Re: Fortran archaeology, Upcoming DFP support in clang/LLVM

<t4s4mn$15n4$1@gal.iecc.com>

 copy mid

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

 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: Fortran archaeology, Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 20:52:39 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t4s4mn$15n4$1@gal.iecc.com>
References: <t4peor$cch$1@dont-email.me> <12d8d684-714c-47ff-ae28-79897a5bbbddn@googlegroups.com> <t4s130$p3o$1@newsreader4.netcologne.de> <67754cbf-fcbf-4ce2-887d-6c6b55087427n@googlegroups.com>
Injection-Date: Tue, 3 May 2022 20:52:39 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="38628"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <t4peor$cch$1@dont-email.me> <12d8d684-714c-47ff-ae28-79897a5bbbddn@googlegroups.com> <t4s130$p3o$1@newsreader4.netcologne.de> <67754cbf-fcbf-4ce2-887d-6c6b55087427n@googlegroups.com>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Tue, 3 May 2022 20:52 UTC

According to MitchAlsup <MitchAlsup@aol.com>:
>On Tuesday, May 3, 2022 at 2:50:59 PM UTC-5, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>> > in 1982 I was on a project that built a FORTRAN runtime library. We built
>> > the WRITE routines so you only pulled in the data formatters you actually
>> > used, not the entire suite of potentials.
>> How did you deal with formats created at run-time?
><
>The FORTRAN of that era did not have those.

Sure it did. Fortran 77 let you put your format statement in a character variable.

There weren't that many formats specifiers, so the F77 compiler I wrote just put them
all in the library and interpreted formats at runtime, both static ones from FORMAT
statements and dynamic ones in variables.

--
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: Upcoming DFP support in clang/LLVM

<t4s55s$ine$1@dont-email.me>

 copy mid

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

 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: Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 16:00:35 -0500
Organization: A noiseless patient Spider
Lines: 244
Message-ID: <t4s55s$ine$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 3 May 2022 21:00:44 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="d34dae49020eda54527366dd36476a99";
logging-data="19182"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18v6gjnxsGFOZ+GdY8aiNA1"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:1VPyqvrxAUpiCt+WTQa5wlBccPw=
In-Reply-To: <t4qsuk$77p$1@newsreader4.netcologne.de>
Content-Language: en-US
 by: BGB - Tue, 3 May 2022 21:00 UTC

On 5/3/2022 4:34 AM, Thomas Koenig wrote:
> BGB <cr88192@gmail.com> schrieb:
>
>> Well, that and it answers another mystery: "How could you have fit Unix
>> onto computers with only a few K of RAM?..." Apparently, they didn't,
>> they (somehow) had access to machines in the 70s with MB of RAM.
>
> This turns out not to be the case.
>
> The PDP-11 they started serious UNIX development on had 24 kB of
> memory and a half-megabyte disk.
>
> Source: UNIX: A History and a Memoir, Brian Kernighan, page 52.

OK, this turns it back into being a mystery how it could fit...

When I was trying to gather information, looking up PDP-11 was turning
up things like PDP-11 processor boards for an S-100 backplane with 2 MB
of RAM and similar.

Though, looking some more, I am guessing it is likely this was newer
technology or something... (Apparently both the S-100 backplane and DEC
J-11 processor/chipset were 1980s era technology).

In my case, I have a 32K ROM, of which I manage to fit all of:
A FAT16/FAT32 driver;
A PE/COFF loader;
An LZ4 and RP2 decoder;
Some processor sanity-test code.

How one could fit an OS kernel and still have enough usable space to run
programs into 24K of RAM seems like a mystery.

To make stuff fit, I had to make some compromises, like IIRC, the ROM
version of the FAT driver leaves out stuff like ability to create or
modify files, and also leaves out things like LFN support (so, eg, the
boot image is limited to an 8.3 name).

Granted, it is possible things could be shaved down some more (could
maybe omit things like VFS mount-points or support for directories,
since these are mostly N/A to the boot loader, which assumes the boot
image to be in the root directory).

It is possible that I could eliminate the use of the hardware font-ROM
by having the boot-loader, switch to using 8x8 pixel bitmap color cells
(like what TestKern currently does).

Font ROM would either be replaced with Font-RAM, or potentially this
could be eliminated entirely.

Though, Font RAM still has a few potential use-cases.

This would likely save some LUTs and BRAMs, but would require the Boot
ROM to store an additional 768 bytes for the font bitmap (assuming
20..7F are present).

Not sure of a good way to compact the font further:
A, Using a "7-segment" font, which could reduce storage cost somewhat;
Glyphs would be represented as 1 byte each.
B, Omitting part of the ASCII space:
Say, only having 21..5F, remapping 60..7F to 40..4F
Would save ~ 256 bytes but lose lower case letters.
C, Redraw glyphs as 5x6 pixels (needs 30b vs 64)

Both A and C would require an "unpacking" stage (to convert back to the
8x8 layout for display).

....

Had also had thoughts before that maybe one could do old-style
platformers by effectively using the color-cell display as a background
scene, then using screen offset registers to scroll the scene.

Possibly, the screen area, rather than being 80x25, could be expanded
96x32 or similar (with 80x25 visible), allowing for some off-screen
scratch area.

Or, could use the 80x50 mode (640x400 pixels), or 40x25 mode (320x200).

Had previously added a (mostly unused thus far) feature for hardware
sprites.

One other random idea would be, what if there were per-row offsets
(added to the master offset for each 8-pixel row of color-cells)? ...

Had also considered ideas to allow 2 layers of character cells, but this
would add some amount of "technical challenge" (would likely require
multiple ports into the VRAM; most likely splitting the VRAM into two
128-bit planes, each holding an 8x8x1b color cell and a pair of RGB555
endpoints and similar).

Well, all this as opposed to just using the 320x200 16bpp hi-color mode.
Though, if drawing into an off-screen buffer, and copying this to VRAM
each frame, a fair chunk of the total CPU time goes mostly into the code
for copying the off-screen bitmap into VRAM.

From stuff I heard, I guess a lot of 70s era CRT graphics were mostly
"racing the beam" style, with people configuring the contents of the
video registers ahead of the raster beam (say, copying a row of text at
a time from RAM into internal display memory whenever the raster beam
hits the next row).

Not sure if anyone was using CRT displays or doing graphics programming
on the PDP's, not heard much of this (most stuff I read was implying
that they were mostly using TTY terminals connected over a serial
interface or similar).

Then again, it is possible the "racing the beam to update a row of
character cells" stuff was mostly happening in the TTY terminal or similar.

....

As noted, I wasn't there, pretty much my whole life has been in the era
of x86 desktop PCs and similar. As noted, my first (semi successful)
forays into graphics programming what when I was in high-school, mostly
using OpenGL and similar (with the great migration from raster graphics
to 3D acceleration having happened a few years earlier).

(Well, games that were around during high-school were mostly things like
Quake 3, Half-Life, ...). IIRC, games like Quake 1/2 and similar came
around when I was in elementary school. Portal and similar didn't come
out until I was taking college classes.

In my early years, I played Wolf3D and Doom and similar as well (*1),
and partly found them interesting because the source was available
(though, when I was at that age, I couldn't make much sense of the
Wolf3D or Doom source, so my C programming journey mostly got going with
prodding around with the Quake and GLQuake source, and mostly just
breaking stuff at the time...).

*1: Mostly because Quake was pretty much unplayable on a 486 DX2-66,
which is what I had access to at the time. Doom and Wolf3D and similar
ran pretty good though. It was also running DOS + Windows 3.11, but
newer PCs were generally running Win9x. DOS + Win 3.11 was still pretty
common on school computers at the time (though, by high-school things
had mostly moved over to Win98 and occasionally WinXP).

In elementary school, I also had an 8088 which I got second-hand from a
relative (the 486 being my parents' computer at the time).

This relative had a Pentium, which (unlike the 486) could get playable
framerates in Quake. IIRC, they were also running Win9x.

I had a few relatives (mostly aunts and uncles; generally Gen-X) who had
Genesis and SNES and similar, and also my parents had a NES (the NES
existed before I did). Never really got much into console gaming though.

But, in my projects, I ended up taking some inspiration from these eras
of hardware (and the "clever hacks" people used to program it all, ...).

Though, in some areas, the "line of demarcation" between 1970s and 1980s
technology is a little fuzzy (a lot of the 1970s tech being "like 1980s
tech, just generally worse...").

Technically a world I had only ever seen through the lens of TV shows
and similar.

One can usually identify something is 70s aligned because the decade
mostly followed an "everything is brown" color scheme:
Brown or wood-grain finish, probably 70s;
Particularly if it has big/obvious buttons or toggle switches;
No LEDs on 70s tech;
Also TV cables used 2 parallel wires rather than coax;
These being connected using screw-terminals and spade connectors;
Presumably non-polarized;
...
Gray or Beige, 80s to 90s;
Smaller buttons, LEDs (red/yellow only for 80s);
No toggles, replaced with dual-state buttons;
Lots of molded plastic;
Coax and RCA connectors;
...
Black, mostly 2000s.
Blue or Purple LEDS show up here;
Also glowing 16-segment displays were popular;
2000s: Pointy molded plastic and internal LED glow appear;
...
2010s to present:
Still mostly black, replace constant-color glows with cycling RGB;
Lots more HDMI and similar.

I guess, further back:
60s: No real tech in the modern sense.
There were apparently cabinet-sized TVs, rotary phones, and record
players I guess;
Also people having overly elaborate hair-styles and bright-colored clothes.

Though, the bright-colored clothes thing returned in the late 80s /
early 90s for a while, albeit with more "funky molding" and big pointy
shoulders. The 80s "big hair" was more poofed and bleach-blonde, rather
than 60s where they would make it look like a big hair helmet or molded
shape or similar.

Older decades:
Pre-1900: N/A, no TV or movies;
1900s-1920s: Black and white, captions only.
1930s-1940s: Black and white, with sound;
Except "Wizard of Oz" being both color and 1930s.
1950s+: Usually color.

I guess at one point, there were also telephones that were a wooden box
with a hand-crank and similar, or:
Wooden box: 1800s ?
Rotary phone: ~ 1910s .. 1970s
Touch-tone phone: ~ 1970s .. 1990s.
Cordless phone: 1990s;
Flip-phone: roughly 2000s (*3);
Smartphone: 2010s .. present.

Sometimes seen in movies:
A giant brick phone and/or suitcase with a handset (roughly 70s).


Click here to read the complete article
Re: tiny little computers, was Upcoming DFP support in clang/LLVM

<t4s5b4$15n4$2@gal.iecc.com>

 copy mid

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

 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: tiny little computers, was Upcoming DFP support in clang/LLVM
Date: Tue, 3 May 2022 21:03:32 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t4s5b4$15n4$2@gal.iecc.com>
References: <t4peor$cch$1@dont-email.me> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
Injection-Date: Tue, 3 May 2022 21:03:32 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="38628"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <t4peor$cch$1@dont-email.me> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Tue, 3 May 2022 21:03 UTC

According to BGB <cr88192@gmail.com>:
>Well, that and it answers another mystery: "How could you have fit Unix
>onto computers with only a few K of RAM?..." Apparently, they didn't,
>they (somehow) had access to machines in the 70s with MB of RAM.

Yes, we did. The most memory you could put on a PDP-11/45 was 248K,
the 256K bus address space minus 8K for the I/O devices. Each process was
limited to 64K of code and 64K of data. Memory was expensive and many
real systems had 128KB or less.

The original Ritchie C compiler was two passes, a third optional
peephole optimizer, and then the assembler. As I recall each pass was
about 24K bytes. Recompiling the system took a while but that was
mostly because the disks were slow.

>Well, along with having integer multiply/divide/... in hardware.

The 11/45 had mutiply and divide but I wrote code that ran on a 11/05 by
carefully not writing things that would require multiplying. The compiler
was smart enough to use shifts where it could.

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

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor