220 39389 article Path: news.gmane.org!.POSTED!not-for-mail From: David Brown Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Wed, 25 Jul 2018 09:03:59 +0200 Lines: 76 Approved: news@gmane.org Message-ID: References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> <4e6835ac-6975-4c89-81c4-fc038d004cb7@isocpp.org> <1957969.uOyN2Jk7ag@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1532502123 31644 195.159.176.226 (25 Jul 2018 07:02:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2018 07:02:03 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDP6R2XHXIARB2GB4DNAKGQE3NCBZVI@isocpp.org Wed Jul 25 09:01:59 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f197.google.com ([209.85.208.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fiDo6-000870-QC for gclcip-std-proposals@m.gmane.org; Wed, 25 Jul 2018 09:01:58 +0200 Original-Received: by mail-lj1-f197.google.com with SMTP id p8-v6sf1575426ljg.10 for ; Wed, 25 Jul 2018 00:04:09 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1532502249; cv=pass; d=google.com; s=arc-20160816; b=gW1Ks1xS3BmwkBSeoLEpXvXUa4laSFsNrYaCq6JFyKV4F/+EVDMIQhXCxTcALn56z7 0ap3U7HHc3HCzP4CQo+z8s4RVOLn0B340z0TQi6LkFA9s2fBsue4YASrQD8u/U/uL2yW TUDKVIdFAkzIlo8kydaB9MVG19Vvs/2s65Qgh4/mjb5xUJ4NwbcNieU8lYX+/ekwJymQ Yb32PiT2KATlGIGmlTpjZpLVrLju3bvrv9HF2eLgw17nCXc5EdDOW8kjbz637eg8yqof qLAktlPokGPzvYG9NmHN6wExF+PJkyu+lN71ynZfgdRr4ySYbAvpaQ0e6o16nyjEx+vI m6dA== 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:in-reply-to:user-agent :mime-version:references:message-id:lines:date:subject:from:to :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=7IErCS8l3GCnPjdzK/vUAzYADspOt4n28oXWS93D/mo=; b=X/Sza/PbDOUhfvknY4pLomQ9MW98EcKcEwZ9WJIn5H049UcbWJ5SOz4AC+TZ4dIUQ1 jTaPLzogdrotLjwD0ekuAxSflT62OPQMwcLSMJ/HJOHtDUEN5BCihNzaZOKzLNXrmJLI qp9v6MEL5JEWPjajirUW3fhNh/TN79ElllzHUbKSHxVL8VF2ncG8GCUWDUDApduYUTcE oykrqk/TcxTJJCt014VHMwzSt3cOATt3O7zE7f9o+/0iEnO1dHBK0QuKW6MlrcFwP9fg NLwjrJ0dstxle3I8eMD8JGuJ2q60canZ2mBZeqYaRWIBa22jCKU0oxy5vb1cWWzATHQf HOnQ== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:date:lines:message-id:references:mime-version :user-agent:in-reply-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=7IErCS8l3GCnPjdzK/vUAzYADspOt4n28oXWS93D/mo=; b=jlB+V5Z7SFHJWFdSOIuDEp4/MHlzAjQzR9SF8bt3VQ0EAfny89t+EIsCVq8l5jU3lA KIR9hT9nCjXEWuh0kjBZqxR8kZEjCVQy4kcpB602DI1oPFEeiwDXAaKsEUJJIgzZH3Ga EQMZqnGwJfcvMWROh/Ccw3G4MXTphGIxxGcvwnsbo6X0vKhAPumxB1n58mTiCmg19fff HNuD68+e4emNfQMw5pKA285gSpr53DQ70AkRzmXa4B0D7V1hDSVXxoRhu+lnto4rspqk ARPq5j9IFPSCkeje09A5HIZvXNtTpWnMnfzxmYNg4cCpyFgJOH0zUtsKddNgCjECE5KE dAQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:user-agent:in-reply-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=7IErCS8l3GCnPjdzK/vUAzYADspOt4n28oXWS93D/mo=; b=rEaJNqOYmgOmNppN8ToG9QVKkSrn2GYKGTyiQNNciC/zIUUQerWuh6QF+8c93u7tVv TdtK94FXBRdG//emXoPjszLII41N4tshAViFhYMwDViCy8MMQwrzWdimQXr0sbOQy+CD jqrPzrbCHZD5dCGPXZKw7zLIlEp1f+WWTefPYlRre+Vw2Z9h89m6JnqSVfHhj4+mZhHF gM59H75UU4mM3YhAnToen9Nj4da82MJXNUIHPkQekEJrY21eM158x/ERuQXZEKzsKhb5 CfzdIyj+sw8RCe9ITiUjbDMl/NukqDWHvZHQ0sGfGG/0d4QCMrFgXIg2Xvg/wyoNTc+A XU1g== X-Gm-Message-State: AOUpUlHKUKmetTjmI6cIzLkPWZSVnCW8zRM5f98GF13Pag8Yn1uEO7s1 zXChg2xLSjPmVwYHODo9310= X-Google-Smtp-Source: AAOMgpcjftM5U79B3xQ0kgo7HiyzMdIG7JnFJ0lJWDXcONa9rbbJGoFTD5DLXmx7RWEUpzsdbQZJ6A== X-Received: by 2002:a2e:350b:: with SMTP id z11-v6mr1154123ljz.6.1532502249599; Wed, 25 Jul 2018 00:04:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a19:cb49:: with SMTP id b70-v6ls640901lfg.13.gmail; Wed, 25 Jul 2018 00:04:08 -0700 (PDT) X-Received: by 2002:a19:1190:: with SMTP id 16-v6mr12785662lfr.122.1532502248253; Wed, 25 Jul 2018 00:04:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532502248; cv=none; d=google.com; s=arc-20160816; b=lsiLfeEwJwwBzOsLr4RyHN7kK3yBVfLWiKCpXRpIdsshaB3NPsswAEJubR4Wymy4xE okxs4wzDMGpzOulzncupUwn15N0ASGP6S1s00H+pcx9zGJ/xwZnLGdrYFAbBxT/iMTAe wTCm3hADDoHR1XGvz52ZNhVIAPfUU5wSnug6cA2SxAUhMfT5cTMBGW8F7FAZQGa+E6TU JOJZhP5Qz/XiTyD3ocPJJ9/h4RlCsrHmURaaurBR62qog0AGXJ61+/Q6QLT+m1UA+7ga yN+V4lhzfbeSDRaj60PQvqahKgUiC7YpyW61adYAgJWtsvJkFSlXiGA1EBjzlrta1yvc NM7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:user-agent:content-transfer-encoding:mime-version :references:message-id:lines:date:subject:from:to :arc-authentication-results; bh=gqNGKsD1i1C1i1GdqQE9fx0FQWcskWcD8G7QPAjc6W8=; b=Dc7V7rEe3huU1YyGPwkBROsmdlwP5TFJX+S94YzF4+01qf/NmeRhUGfZoQFDNXUZ6x YQn6ETsP8+Iky5uw2Q2z5XExGnwi2tvY533zoqAFeQ32dMQMYia167GfofJiT5ZQeOHN IslsthQVahJOT5IUFWeWVLu2YJV2Ql2xSCyAQIPvkBvdwGtz+DPrfhMpsC9tsFnys4Qg TaVu5BVZ/E9g6AbID5lJLzaTl0dRkBVv0Kns7u/7PM4uOjQLdyTicMjxQamt/RuMFnhe ysOmM29vxt7CKNXypkCzJerJ+RKmwTpv7lPrmO1jQCOck2WGDv1Rg3R1t94MUHosIBu7 OAQA== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org Original-Received: from blaine.gmane.org ([195.159.176.226]) by mx.google.com with ESMTPS id q63-v6si5300989lfd.282.2018.07.25.00.04.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jul 2018 00:04:08 -0700 (PDT) Received-SPF: neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) client-ip=195.159.176.226; Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fiDo2-00081m-Cf for std-proposals@isocpp.org; Wed, 25 Jul 2018 09:01:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 69 Original-X-Complaints-To: usenet@blaine.gmane.org In-Reply-To: <1957969.uOyN2Jk7ag@tjmaciei-mobl1> X-Original-Sender: david@westcontrol.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org 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:39389 Archived-At: On 24/07/18 21:27, Thiago Macieira wrote: > On Tuesday, 24 July 2018 06:16:42 PDT David Brown wrote: >> I am reluctant to be so confident about the effects here - I really >> don't think you can generalise and say these stalls will never occur. I >> think it will depend a lot on the cpu ISA, the details of its >> implementation (scheduling, out-of-order execution, register renaming, >> pipelining, speculative execution, etc.), and the type of code you are >> dealing with. On many cpus, there are quite a lot of instructions that >> use or affect the carry flag (or any other flags) - these pose a >> challenge for scheduling. They also pose a challenge for the compiler, >> if it would want to use such instructions between the call to "foo" and >> the check for "foo.error". >> >> It may be fair to say that using the carry flag here would not cause >> much in the way of stalling or delays - but I would not say "never" >> without a lot more thorough analysis with a range of different processors. > > That's entirely QoI. If the compiler that targets this particular system where > setting or testing a particular flag is slow, the compiler can simply choose > another way of returning the information. Exactly. Well, /almost/ exactly - it could be a problem for ISA's where the cost of using a carry flag is cheap (cheaper than using a standard bool in a register) on some implementations and costly in other implementations, since they need to share the same standardised ABI. (I am thinking primarily of the x86 world here, where there is a huge variation in the implementation details.) This would be easier if it really was the compiler that could make the choices here - but the proposal is for an ABI change, not just an internal compiler choice. > > Let's take another example of a CPU without flags: IA-64. Instead of having > flags, the CPU has 1-bit predicate registers, which are set or unset depending > on the comparison operation that was performed. So IA-64 could then use one of > the scratch predicate registers as an extra return value. There are 10 of > them. > > Another example is MIPS: it has no carry flag and no predicate register. In > that case, it would need to use an extra register (currently used for scratch) > with either a zero or non-zero value, which would allow the caller to use the > BNEZ instruction to jump to the failure path. Fortunately, MIPS has plenty of > registers, so it can do that. > > This is up to the ABI documents for each platform to determine. > Indeed. My point was merely that using a carry flag would not necessarily be "zero overhead" even on cpus that have a carry flag. For different cpus, different solutions would be more efficient. All in all, I am sceptical to the idea that using a carry flag would be a big enough win on any platform (except, perhaps, on some small microcontrollers) to be worth the massive complications involved. If the whole concept were handled using a regular C struct and union with a bool member, then it would work already with existing tools and ABI's - it is merely syntactic sugar in the compiler front-end, rather than a major change throughout the chain. (Of course, there is nothing wrong with defining an ABI to say that a "bool" return, either in a small struct or stand-alone, is returned in a flag or predicate register - just as the ABI defines register choices for different sized integers and floats in returns. Then the benefits would be seen on all functions returning a bool, not just these proposed exceptions.) -- 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/pj978s%24tjv%241%40blaine.gmane.org. .