From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id E2419BC0B for ; Fri, 8 Dec 2006 12:09:16 +0100 (CET) Received: from oden.vtab.com (dns.vtab.com [62.20.90.195]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kB8B9GPN018522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Dec 2006 12:09:16 +0100 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id CEE5726EF1C; Fri, 8 Dec 2006 12:09:15 +0100 (CET) Received: from virtutech.se (alfredo.hq.vtech [10.0.0.52]) by oden.vtab.com (Postfix) with ESMTP id AE63326EF1B; Fri, 8 Dec 2006 12:09:15 +0100 (CET) Received: (from mattias@localhost) by virtutech.se (8.11.6/8.11.6) id kB8B9CB22752; Fri, 8 Dec 2006 12:09:12 +0100 Date: Fri, 8 Dec 2006 12:09:12 +0100 Message-Id: <200612081109.kB8B9CB22752@virtutech.se> From: "=?iso-8859-1?q?Mattias_Engdeg=E5rd?=" To: skaller@users.sourceforge.net Cc: jonathan.roewen@gmail.com, pal_engstad@naughtydog.com, caml-list@inria.fr In-reply-to: <1165545466.6979.20.camel@rosella.wigram> (message from skaller on Fri, 08 Dec 2006 13:37:46 +1100) Subject: Re: [Caml-list] if (n:int) < 0 then (-n) > 0 is FALSE Content-Type: text/plain; charset=iso-8859-1 References: <45785E27.8050804@naughtydog.com> <200612071943.kB7JhC522308@virtutech.se> <1165545466.6979.20.camel@rosella.wigram> X-Virus-Scanned: ClamAV using ClamSMTP X-j-chkmail-Score: MSGID : 457947DC.000 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 457947DC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; mattias:01 mattias:01 compiler:01 statically:01 hmmm:01 decoding:01 optionally:01 ocaml:01 slighly:01 ocaml:01 compiler:01 semantics:01 alu:98 integer:01 integer:01 >> (Signed overflow is not legal in C (undefined behaviour), and a decent >> compiler will warn this can be detected statically.) s/warn/warn when/ (sorry) >Hmmm. In the usual full word register operations most CPU >have an overflow flag which a single conditional branch can >detect. Given branch prediction the branch is unlikely to be >taken the cost of detection is probably extremely small, >provided you have control at the assembler level. Even well-predicted branches are not free. They pollute the BTB, make the code bigger (consuming I-cache), consume various resources (decoding, instruction queue, ALU, rename registers etc) and as integer operations are very common these all add up. The ideal architecture in this regard would be one with optionally trapping integer instructions, and very fast user-mode traps. >Ocaml has slighly messier representation with one less >bit, but i guess overflow detection wouldn't be so hard >or all that expensive -- but I could be wrong, perhaps >someone on Ocaml team has looked at this can can comment? I suppose it wouldn't be impossible to add a compiler flag to change the integer overflow semantics from wrapping to trapping. Doing so for constant expressions (the original complaint in this thread) would probably be less work.