220 40341 <970A16E4-63F6-4DAB-B3A3-EEDA0AF4C2A8@me.com> article Path: news.gmane.org!.POSTED!not-for-mail From: "'Alisdair Meredith' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: 128 bit integers Date: Fri, 05 Oct 2018 13:10:09 -0400 Lines: 204 Approved: news@gmane.org Message-ID: <970A16E4-63F6-4DAB-B3A3-EEDA0AF4C2A8@me.com> References: <4111d349-b11d-45a4-aa06-d871d8efb20e@isocpp.org> <618c6701-abd5-4caa-8917-c1a15a5840d5@isocpp.org> <869310a4-67f1-4594-8157-e33ae7d7e0f3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-08A3EE0F-11BF-480A-A64A-C3756C456C62 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1538759311 19316 195.159.176.226 (5 Oct 2018 17:08:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 Oct 2018 17:08:31 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDWML5V6SIARBDFW33OQKGQE7Q5WYGI@isocpp.org Fri Oct 05 19:08:26 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt1-f200.google.com ([209.85.160.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g8TaU-0004wi-K4 for gclcip-std-proposals@m.gmane.org; Fri, 05 Oct 2018 19:08:26 +0200 Original-Received: by mail-qt1-f200.google.com with SMTP id a15-v6sf13027569qtj.15 for ; Fri, 05 Oct 2018 10:10:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1538759437; cv=pass; d=google.com; s=arc-20160816; b=uaAh1bBGzE49lU8EqClJvRikGgTv7GdlyxskzBsi0c0DDmmQO2uOXUi4RmUV6a2oFN p30Km6gzzCDzJb73A1cbOrOqa5gtudTJhE1oTurjueDtLqDr0zXs2quWZi7Y8gkthXv0 ayAQ7K3hLQZll3z3mO3mwij/30qa0zBMJwApG+ouhb+BZcnD7yU/tc2T6jFzWZNrhAfR 4U6DI2Q96f1aFSk5OWakumtWVaH7WHqQ3Oh4QRytvjNwX6PY8zWslzmP1bGQLumxc/Ek U9dWq73vRk9zGKo6K97wCTit5v3NUUMl3xw7D3Jl5JhUAuCLcoKPdGizZJmAzhLmiH+U NrHg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:in-reply-to:references :message-id:subject:date:mime-version:content-transfer-encoding:from :dkim-signature; bh=o3R0PLag2Q9+vExHqlWasd02r6568C1cQdKUXn6RP+I=; b=hLSeqrx+PLbk4Y1KBu/jwerGEK50qW/xAfHqC8f6btR3daCrb49njusWvNEeas2+wL +nf/6n8WIy0XCgcQOoq/qUTaXUG+xrGLJLEXI41+vwZt84qUgd9jna+eYX3FZCoWNUlG BogfbrADCzLGv7Cg19aUftRkiZd4We8nut7xDxC9IBKo0/0tM7L/cRXepy9t2lY2xM8O in7CJaWKYjUqxqYjF0BgEbpyQdncWb6cIdgMlyFzSG8BWANzZJSGkqz0XE21WLDL2dA0 wp9PULXGhJT3iszURmPfyMlboPZe1CtQE7RdMLezvSQD/TojPf//ZWp/Pa74bzZeWZy9 C1jw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@me.com header.s=04042017 header.b="HXfxhnk/"; spf=pass (google.com: domain of alisdairm@me.com designates 17.172.80.96 as permitted sender) smtp.mailfrom=alisdairm@me.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=me.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=o3R0PLag2Q9+vExHqlWasd02r6568C1cQdKUXn6RP+I=; b=BFtmQDNf36xrjhBKq7UVxOc1B2eoNnJ9v8b9UrfiUbSDnJqucrmO1l1SdqeZp1s7CN JPrZd14uud1B2kdnd34t4weUtxM3+yM59tvuAAkXJ5Icm8h7d/09So2Jkv86esvTe7E8 3u6tI93g2ZyMU+mpICNb2nnu7gZfPhhvHG/ouuOoPmv0zPWHPPPR8ZTY9sIswBC+9ETJ Lk7IIxadsKj3zf4EcaCPtgOHqqb0FPJHknRBlq73vlCe3UMCma+fipmiHRNJm3s3h8oF ZolOnfBAOC02NzHLxvJ2QAeA0fokek+gFVuE7c6cKnDyDhzFVZPxzZyKEnsm3R9PE0n3 rShg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=o3R0PLag2Q9+vExHqlWasd02r6568C1cQdKUXn6RP+I=; b=Akl0aaa1sfNubYN8MpS0pQd1HrvXWZ0iR9UcFPHC9q5pT19d+IpFAU9GMSpdNGR6u+ 5/qe9NBaebego3b3iJMFp6X6mgWTp+aEKGXSJb2v7/rxwuOWBspUaDx2xfAwwkw9sQZ1 I2JoCnOnfHE8j+yH4bt/bJDQr30rdj14KOGjXvU9W5U6ZkOe2qfoxfOfkVOmpz/7XFUh 2uStlCrl2O6jCSkmJU5y7Ib/3tSwHJKBVBvxPsoi35zn1uac6inKL+d3CDX7zsa6bd79 JccfbTqIUlEDGHh2UHO28oYI7cHsJgqs4GESa0DgJN7VW2Tdr/4jPlGbHfuZifNVxgpt 9d1 X-Gm-Message-State: ABuFfogQ5oKWCDvNG2k5JYUxmo2sNb0oqVRj1qXQGyL9lQQgOfBvjBAv wykCKSQuEVeb7KOmYtEKJYw= X-Google-Smtp-Source: ACcGV60soL76QAK5jcbGELXjbPFWEiXRymhvYU0wCnIyvH7+pD5FBXdD/Le4vBT76f56i46E5rvHvw== X-Received: by 2002:a37:dd14:: with SMTP id n20-v6mr8485919qki.43.1538759437009; Fri, 05 Oct 2018 10:10:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a37:6105:: with SMTP id v5-v6ls3278210qkb.13.gmail; Fri, 05 Oct 2018 10:10:36 -0700 (PDT) X-Received: by 2002:a37:17e5:: with SMTP id 98-v6mr9817031qkx.42.1538759436100; Fri, 05 Oct 2018 10:10:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538759436; cv=none; d=google.com; s=arc-20160816; b=S+CAe4UhHzuEHBN9VDMNO5n72hbPDlR7P3Nm5GOH2BdYegydDOOnaNGWWoYNs0yrcn jbrU3yh9Uw7L6P+pAT7FPhlbKLm4yGpTNWlTYG7D7BQec6fr8VJid/A4xkQd6jv5KFD5 coiTnDpanLTQ5jBSrlKwg4Q49JHu228h3ppnCSCq/Q5Rp7IVI+IMc/kvNyqfVqyp3bhI 46GJeBEPxCuVajW4Zv9ct3ASMYDsiMpWz/IZTdl2CsPVObnpBI+67BDsKcN+zxDF7710 sdH1tgWkuVQ5TZMXMshASleJjyQdjI7b4kRYAGgBk8CoOMwMXNWIhexL3Xqjy+Picq9y NT3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:in-reply-to:references:message-id:subject:date:mime-version :content-transfer-encoding:from:dkim-signature; bh=+voO+N1qE77gbTV5aD181I34G21+UvQJsy+h5TGNt8c=; b=C7MFl93ck46+wQPMoI2wa2PAVPeZsKatxiU7TrNTM6RZZKyn+gKu9ZqZ1dvVMT/KSP xaVpm9MSTgbkod+flt0dnFq4Mk2rA8NEqVvSHuz7p9KD4Yho2LF5R1yC1gs90sIBtCFf DPgoVUW5QXZfnl0v9t1ACfh+WDglrIoZpFbgoImWf5UtwGbK5JGwG3Q8D1yWKshFGbji Xg0BssAzRmD9zv7IRpagtGKfO3cMvu2RJL/DC6lAnrWO/difQ9Co+lm3HugYSNlw8Ozr HyTx8yw0Zexha16Igy69+/MKdYi+R65nIUQetjPmnDyPvf5Q5ddamVN8g4uusE7yADMe 6Nyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@me.com header.s=04042017 header.b="HXfxhnk/"; spf=pass (google.com: domain of alisdairm@me.com designates 17.172.80.96 as permitted sender) smtp.mailfrom=alisdairm@me.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=me.com Original-Received: from st11p00im-asmtp002.me.com (st11p00im-asmtp002.me.com. [17.172.80.96]) by mx.google.com with ESMTPS id 199-v6si1111454qki.344.2018.10.05.10.10.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Oct 2018 10:10:36 -0700 (PDT) Received-SPF: pass (google.com: domain of alisdairm@me.com designates 17.172.80.96 as permitted sender) client-ip=17.172.80.96; Original-Received: from process-dkim-sign-daemon.st11p00im-asmtp002.me.com by st11p00im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PG400900XF5A600@st11p00im-asmtp002.me.com> for std-proposals@isocpp.org; Fri, 05 Oct 2018 17:10:11 +0000 (GMT) Original-Received: from icloud.com ([127.0.0.1]) by st11p00im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PG400J25YCXZY10@st11p00im-asmtp002.me.com> for std-proposals@isocpp.org; Fri, 05 Oct 2018 17:10:10 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810050170 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-05_09:,, signatures=0 In-reply-to: X-Mailer: iPhone Mail (16A366) X-Original-Sender: alisdairm@me.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@me.com header.s=04042017 header.b="HXfxhnk/"; spf=pass (google.com: domain of alisdairm@me.com designates 17.172.80.96 as permitted sender) smtp.mailfrom=alisdairm@me.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=me.com X-Original-From: Alisdair Meredith Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40341 Archived-At: --Apple-Mail-08A3EE0F-11BF-480A-A64A-C3756C456C62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Does your proposal address _Atomic in C, and atomic in C++? I wa= nt to be sure that no-one is laboring under conflicting assumptions here, e= ven when it means stating the (apparently) obvious. Sent from my iPhone > On Oct 5, 2018, at 11:42 AM, Niall Douglas wro= te: >=20 >> On Friday, October 5, 2018 at 2:18:30 PM UTC+1, John McFarlane wrote: >> If you're collecting related papers, you might want to mention P0539 whi= ch is a 100% serious paper. >>>=20 > My C proposal paper is actually a direct response to P0539, and it discus= ses what I think are showstopper problems with that paper, and why we need = a language solution instead. As I wrote: >=20 > WG21 is currently proceeding down a library-based path for implementing > extended precision integers (https://wg21.link/P0539), but my issue with > it is that it is very hard to get the compiler to predictably generate > optimal code with a library only solution. In particular, compilers fail > to spot when they can use carry-adds or carry-multiplies from hints > provided by generic C or C++ code. This is why I have become convinced > we need a language based implementation so compilers know exactly what > they are supposed to do. Hence me coming here to WG14. >=20 > Current proposal being discussed on the WG14 reflector looks as follows: >=20 > 1. For any integer type excluding _Bool (char, short, int, long, long lon= g), one may extend it into an extended arithmetic type by annotating it wit= h "_Wide(N)": >=20 > - _Wide(4) int > - long long _Wide(2) >=20 > This simply tells the compiler to emit the add-with-carry or multiply-wit= h-carries instructions necessary to increase the precision of the specified= arithmetic type. And before anyone asks, yes it is legal to widen small ty= pes: >=20 > - _Wide(2) short (NOT an int) > - _Wide(4) char (NOT an int) >=20 > 2. These wide integer types are not integral types, and thus do not affec= t intmax_t etc. ABI remains unchanged. >=20 > 3. As the compiler knows the size of these at compile time, and that they= will always be some twos power multiple of an integral type, implementatio= n cost for compiler vendors is straightforward. *Optimising* them is hard, = but then so is optimisation in any case. >=20 > 4. These extended types would have the same ABI as a struct of however ma= ny of their integral type e.g. _Wide(4) long int has the same ABI as struct= { long int[4] }. So they'll get passed mostly by reference, whatever the c= urrent calling convention says. Nothing changes for the calling convention. >=20 > 5. My current feeling is that these wide arithmetic types should have the= alignment of their integral type but doubled as necessary. This enables th= em to "stand in" for types hardware available on bigger CPUs. It also enabl= es SIMD vectorisation by optimisers - AVX-512 CPUs can do 8x 128-bit intege= r adds four times faster than with the scalar instructions for example. >=20 > 6. I'm still deciding on whether to support _Complex or not. >=20 > 7. I'm minded that wide multiplication does not emit doubled precision ou= tputs, but that instead we gain a new multiplication operator whose result = type is double the precision of that of its input types. My suggestion woul= d be **. That new operator would apply to the integral types too. In partic= ular, Intel CPUs have had a special opcode for 64 bit x 64 bit =3D 128 bit = multiply for a while now, but making use of it without intrinsics has been = hard. >=20 > Niall >=20 > --=20 > You received this message because you are subscribed to the Google Groups= "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit https://groups.google.com/a/isoc= pp.org/d/msgid/std-proposals/b5d854b4-c24e-4a3f-8fcc-3c793527b791%40isocpp.= org. --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/970A16E4-63F6-4DAB-B3A3-EEDA0AF4C2A8%40me.com. --Apple-Mail-08A3EE0F-11BF-480A-A64A-C3756C456C62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Does your proposal address _Atomic in C= , and atomic<integral> in C++?  I want to be sure that no-one is= laboring under conflicting assumptions here, even when it means stating th= e (apparently) obvious.

S= ent from my iPhone

On Oct 5, 2018, at 11:42 AM, N= iall Douglas <nialldouglas14= @gmail.com> wrote:

On Friday, October 5, 2018 at 2:18:30 PM UTC+1, J= ohn McFarlane wrote:
If you're = collecting related papers, you might want to mention P0539 which is a = 100% serious paper.

My C proposal paper is actua= lly a direct response to P0539, and it discusses what I think are showstopp= er problems with that paper, and why we need a language solution instead. A= s I wrote:

WG21 is currently procee=
ding down a library-based path for implementing
extended precision integers (https://wg21.link/P0539), but my issue with
it is that it is very hard to get the compiler to predictably generate
optimal code with a library only solution. In particular, compilers fail
to spot when they can use carry-adds or carry-multiplies from hints
provided by generic C or C++ code. This is why I have become convinced
we need a language based implementation so compilers know exactly what
they are supposed to do. Hence me coming here to WG14.

=
Current proposal being discussed on the WG14 reflector looks as = follows:

1. For any integer type excluding _Bool (char= , short, int, long, long long), one may extend it into an extended arithmetic type by annotating it with "_Wide(N)":

 =   - _Wide(4) int
    - long long _Wide(2)

This simply tells the compiler to emit the add-with-carry o= r multiply-with-carries instructions necessary to increase the precision of the specified arithmetic type. And before anyone asks, yes it is legal to w= iden small types:

    - _Wide(2) short (= NOT an int)
    - _Wide(4) char (NOT an int)
=
2. These wide integer types are not integral types, and thus= do not affect intmax_t etc. ABI remains unchanged.

3.= As the compiler knows the size of these at compile time, and that they will always be some twos power multiple of an integral type, implementation cost for compiler vendors is straightforward. *Optimising* them is hard, but then so is optimisation in any case.

4. These extended types would have the same ABI as a stru= ct of however many of their integral type e.g. _Wide(4) long int has the same ABI as struct { long int[4] }. So they'll get passed mostly by reference, whatever the current calling convention says. Nothing changes for the calling convention.

5. My current feeling is that = these wide arithmetic types should have the alignment of their integral type but doubled as necessary. This enables them to "stand in" for types hardware available on bigger CPUs. It also enables SIMD vectorisation by optimisers - AVX-512 CPUs can do 8x 128-bit integer adds four times faster than with the scalar instructions for example.

6. I'm still deciding on= whether to support _Complex or not.

7. = I'm minded that wide multiplication does not emit doubled precision outputs= , but that instead we gain a new multiplication operator whose result type = is double the precision of that of its input types. My suggestion would be **. That new operator would apply to the integral types too. In particular, Intel CPUs have had a special opcode for 64 bit x 64 bit =3D 128 bit multiply for a while now, but making use of it without intrinsics has been hard.

Niall

--
You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.goo= gle.com/a/isocpp.org/d/msgid/std-proposals/b5d854b4-c24e-4a3f-8fcc-3c793527= b791%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/= a/isocpp.org/d/msgid/std-proposals/970A16E4-63F6-4DAB-B3A3-EEDA0AF4C2A8%40m= e.com.
--Apple-Mail-08A3EE0F-11BF-480A-A64A-C3756C456C62-- .