From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA27831; Thu, 3 Apr 2003 11:29:53 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA27990 for ; Thu, 3 Apr 2003 11:29:51 +0200 (MET DST) Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h339Tp921121 for ; Thu, 3 Apr 2003 11:29:51 +0200 (MET DST) Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Apr 2003 11:29:50 +0200 Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 Apr 2003 11:29:50 +0200 Received: from TVP-MSG-02.europe.corp.microsoft.com ([157.58.40.131]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Apr 2003 11:29:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6895.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Caml-list] Bug? Printf, %X and negative numbers Date: Thu, 3 Apr 2003 10:29:49 +0100 Message-ID: <76A83D32A3D2704C9D01CDC1EFFC8FF6043A5322@tvp-msg-02.europe.corp.microsoft.com> Thread-Topic: [Caml-list] Bug? Printf, %X and negative numbers Thread-Index: AcL5XTkZ6AwaMjmlQc2YL41LlDmglwAY1HsQ From: "Fabrice Le Fessant" To: "Ville-Pertti Keinonen" , "Gregory Morrisett" Cc: X-OriginalArrivalTime: 03 Apr 2003 09:29:50.0668 (UTC) FILETIME=[936628C0:01C2F9C3] X-Spam: no; 0.00; caml-list:01 bug:01 printf:01 runtime:01 mldonkey:01 32,:01 implemented:01 pervasives:01 compiler:01 -bit:01 ocaml:01 int:01 complexity:02 module:03 optimizing:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk =20 > I agree that the OCaml runtime makes good compromises that=20 > work well in practice. Any added complexity would probably=20 > hurt symbolic code, which seems to have had a high priority=20 > in considerations of tradeoffs. Just my two pence: in MLdonkey, int64 are used everywhere instead of int, and instead of int32, which are two small for file sizes. So, it will not benefit from any optimization on int32. However, it would benefit=20 from a new type 'long', that would be at-least a 63-bit integer. Depending on the platform, this type could=20 be implemented either by a traditionnal int (with the integer-bit set, on 64-bit platforms), or by an int64=20 on other platforms. Since in the next years, more and more computers will be 64-bit, and more and more applications will need=20 support for integers in the range 33-bit ... 63-bit, this could be more interesting than optimizing 32-bit=20 integers (using the 'long' type, a program that would have used 32-bit integers, would have the guaranty=20 that the longs are not allocated on 64-bit platforms). Moreover, it can probably be implemented in the=20 Pervasives module without any changes in the compiler. But maybe int32 are already implemented by a normal int=20 on 64-bit platforms ? ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners