220 39295 <5a449c86-b0f4-4b07-b5d6-21b7adbfd63b@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Niall Douglas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Mon, 23 Jul 2018 01:11:45 -0700 (PDT) Lines: 78 Approved: news@gmane.org Message-ID: <5a449c86-b0f4-4b07-b5d6-21b7adbfd63b@isocpp.org> References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> <87240a3d-623f-4f7f-8e7c-fa8c9482fa72@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7856_1220127829.1532333505118" X-Trace: blaine.gmane.org 1532333383 8411 195.159.176.226 (23 Jul 2018 08:09:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2018 08:09:43 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRBQM323NAKGQE6QJR55A@isocpp.org Mon Jul 23 10:09:38 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f200.google.com ([209.85.213.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fhVuR-00023e-V5 for gclcip-std-proposals@m.gmane.org; Mon, 23 Jul 2018 10:09:36 +0200 Original-Received: by mail-yb0-f200.google.com with SMTP id r2-v6sf9486146ybb.4 for ; Mon, 23 Jul 2018 01:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=0tMYSjAnAcGRaSYBvAb4EUYsTEQuF6t43di2Rb85zjU=; b=swpYMHq67y0GhIuwuW7Mz7vVpGTmOIKkgvGh66ZR+EhX0G0dAZRY3A+gQ2keYMTMOv 1tdFNKcrL1AjLC8m8dNXYW6f73Hjl0/wjL14NqqpTZbYstH05EAGJBiTj4dpOne/rosT m7qldRGNqmkAcpTuzlqFTgbTBsEygEeXwR4prENWfSULqGUDwHbq4PS6i9xaQRq+rmZx KjmprEiVP9rhKCRiPFWhwgid5qm63Kq4JsWV72QvgnX9k+HV0O8E+m6CLabLleDtCKUe PGJHi+pylB1LaGqzcV4sXg/tEaIdh5S4o5Ci5kvys3vX8p9dLMTP2iaUu/swN74xKASn SREQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=0tMYSjAnAcGRaSYBvAb4EUYsTEQuF6t43di2Rb85zjU=; b=O6C/0RYHQ9dyojKMHPrBY+5uikqVIstwzJTzY5VPVKv3UB0ryj2FUlytU2KYwdE9K9 sBoLYNAfupHE3bqa0IQWzjFbQssLdRigFw/veFOI+qGEZWPCaApnhXFT4IGFD4TJA8wz n9JmbiOwG1JkpLrwUV2P9hCuz9iPwRNchAswGWqYVuA4pBvmgX7Wv2xd57UmvH/9JGjj kZLGw05qtTOa2vgnKx0E0n/wAjgc723IeWHY01a4khkVIVHq2ykG8qnTVy1x9AgrWus+ gtUKIy8ZpV67iVkjSYgQ/5UqxNoM/pSHW9xmg9BaQjgdljD689+ofbx1Bc7mG1nDu7F4 oIsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=0tMYSjAnAcGRaSYBvAb4EUYsTEQuF6t43di2Rb85zjU=; b=Bo0BdMLeesN4w5aLvReWSP/bQlRuNL4eLzkswgHIVnBfGnEE2R28Zdc2KXydpqCHpE nXOouxYKOfWHw20jEb+fpWp5C+N0KOek+lDzh+TqPP2gyK8zMOBP04gbcgcGL/hDfkRu PUxxJcDmqDnPVRDTExoS590zPA8fiFHtCTxFsWsgti/JdUbGMzFnLpPd8MoZYAq3QVeY bW9YbEJNAgLWQOV+LtbZv2LNO84K6m4eOHxmbINf2lqI4V+6wnEfWAW4aLYCNEPGp/Vp DKWxKTBMD202sZggxv2auc5El2zXL+Pmvrx0+oLKhT0leqMkodcZ8DUfDpc7gJcmt1z7 Io8A== X-Gm-Message-State: AOUpUlHANN/UcGoglhK/aRmUUMXHNEEL3xwXiOli9I2fUuQtOSvrZa91 8rnbVYh7a3nQQKKGkc3QeJ/GrQ== X-Google-Smtp-Source: AAOMgpdPEy6R2Tj/9MloP5UDbpYu3KepCeVIEk879UeaGTUZusLSCuZatJht2WQ0j++mt9z6bsQpIg== X-Received: by 2002:a81:3545:: with SMTP id c66-v6mr3207922ywa.164.1532333506724; Mon, 23 Jul 2018 01:11:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:1fc1:: with SMTP id f184-v6ls148497ybf.14.gmail; Mon, 23 Jul 2018 01:11:45 -0700 (PDT) X-Received: by 2002:a25:8448:: with SMTP id r8-v6mr225734ybm.2.1532333505631; Mon, 23 Jul 2018 01:11:45 -0700 (PDT) In-Reply-To: <87240a3d-623f-4f7f-8e7c-fa8c9482fa72@isocpp.org> X-Original-Sender: nialldouglas14@gmail.com 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:39295 Archived-At: ------=_Part_7856_1220127829.1532333505118 Content-Type: multipart/alternative; boundary="----=_Part_7857_2114595971.1532333505118" ------=_Part_7857_2114595971.1532333505118 Content-Type: text/plain; charset="UTF-8" > > Overall, do we really need this 'expected' kind of type to be quite so > constrained and magic, to require an even address etc. etc. > In other words, if the type was actually something that was specified as a > 'normal' C/C++ struct without any of those gymnastics and data packing > or require some carry register etc., would the code be that dramatically > worse that we should require such magic or constraints than a regular type > without all the magic and alignment requirements? > > Not speaking for the above proposal, but in general, it is currently believed that using something like the CPU carry bit ought to be zero overhead on most CPUs, whereas a discriminant stored in the layout would not be zero overhead on more CPUs. The situation of RISC-V, which has no status register, is a particular unknown. Our current best guess is that either we keep the discriminant in the structure, or we fiddle with the return address e.g. offset it by four. There are no good options on that architecture. 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 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/isocpp.org/d/msgid/std-proposals/5a449c86-b0f4-4b07-b5d6-21b7adbfd63b%40isocpp.org. ------=_Part_7857_2114595971.1532333505118 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Overall, do we really need this 'expected' kind of type to= be quite so constrained and magic,=C2=A0to require an even address etc. et= c.
In other words, if the type was actually something that was sp= ecified=C2=A0as a 'normal' C/C++ struct without any of those gymnas= tics and data packing or=C2=A0require some carry register etc., would the c= ode be that dramatically worse that we should require such magic or constra= ints than a regular type without all the magic and alignment requirements?<= /div>

Not speaking for the above prop= osal, but in general, it is currently believed that using something like th= e CPU carry bit ought to be zero overhead on most CPUs, whereas a discrimin= ant stored in the layout would not be zero overhead on more CPUs.

The situation of RISC-V, which has no status register, is a= particular unknown. Our current best guess is that either we keep the disc= riminant in the structure, or we fiddle with the return address e.g. offset= it by four. There are no good options on that architecture.

=
Niall=C2=A0

--
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/5a449c86-b0f4-4b07-b5d6-21b7adbfd63b= %40isocpp.org.
------=_Part_7857_2114595971.1532333505118-- ------=_Part_7856_1220127829.1532333505118-- .