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 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 5E12DBC69 for ; Fri, 30 Mar 2007 11:20:56 +0200 (CEST) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2U9KsmO032001 for ; Fri, 30 Mar 2007 11:20:55 +0200 Received: from ppp36-111.lns2.syd6.internode.on.net (HELO [192.168.1.201]) ([59.167.36.111]) by ipmail02.adl2.internode.on.net with ESMTP; 30 Mar 2007 18:50:50 +0930 X-IronPort-AV: i="4.14,352,1170595800"; d="scan'208"; a="104176316:sNHT33683727" Subject: Re: [Caml-list] int_of_string bug From: skaller To: Andreas Rossberg Cc: Florian Weimer , Yaron Minsky , Oliver Bandel , caml-list@inria.fr In-Reply-To: <460CD180.6080404@ps.uni-sb.de> References: <891bd3390703290927o4e1c6bb5gf8f562fedbc70096@mail.gmail.com> <20070329212931.GG6843@first.in-berlin.de> <891bd3390703291726ue71cfa6re8d4c3d66520e4d9@mail.gmail.com> <878xdfmbm8.fsf@mid.deneb.enyo.de> <1175244271.22118.10.camel@rosella.wigram> <460CD180.6080404@ps.uni-sb.de> Content-Type: text/plain Date: Fri, 30 Mar 2007 19:20:46 +1000 Message-Id: <1175246446.22118.35.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 460CD676.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bug:01 0200,:01 rossberg:01 ocaml:01 integers:01 non-issue:01 ocaml:01 sourceforge:01 wrote:01 wrote:01 integer:01 exception:01 caml-list:01 ints:01 andreas:01 On Fri, 2007-03-30 at 10:59 +0200, Andreas Rossberg wrote: > skaller wrote: > >> > >>> That's a problem too, but there is at least a defensible reason for > >>> that, which is that it is expensive to get integer overflow to throw > >>> an exception. > >> i386 and amd64 have hardware support for that, so it's not very > >> expensive. There are pretty short RISC sequences for the checks, too. > >> > >> MLton uses the i386 hardware support, and I think you can disable the > >> checks, so measuring the overhead shouldn't be too hard. > > > > But there is a difference you may have missed: Ocaml integers > > are 31 or 63 bits, not 32 or 64 bits. > > But it uses the most significant 31/63 bits for ints, so that becomes a > non-issue. ;-) For addition maybe, certainly not for multiplication: one of the operands has to be shifted right 1 place. But it depends on the code generator internal details. You could always shift BOTH operands, do the register calculation, then shift back .. in which case you'd lose overflow detection. The problem is you cannot use the carry bit after the shift back because the bit will definitely be set if the result is negative. >>From what I've seen Ocaml actually uses tricks which also might defeat detection, for example I've seen some use of LEA (load effective address) with the scale by 2 option to load and shift one bit in a single instruction. Processors are quirky about flag bits .. some set sign bit on loading and others don't, etc, so it could be quite messy. This is why C doesn't specify what happens on overflow: it would compromise performance on some processors. -- John Skaller Felix, successor to C++: http://felix.sf.net