From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p84FMDOu026704 for ; Sun, 4 Sep 2011 17:22:13 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAPOWY04SCRkOmWdsb2JhbABDmTaPMBQBAQEBAQgLCwcUJoQXG6BElg+If4YKYASkVw X-IronPort-AV: E=Sophos;i="4.68,328,1312149600"; d="scan'208";a="118279125" Received: from dmz-mailsec-scanner-3.mit.edu ([18.9.25.14]) by mail1-smtp-roc.national.inria.fr with ESMTP; 04 Sep 2011 17:22:07 +0200 X-AuditID: 1209190e-b7c60ae000000a26-65-4e63971962d2 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 85.F0.02598.917936E4; Sun, 4 Sep 2011 11:19:53 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p84FM6Os025140 for ; Sun, 4 Sep 2011 11:22:06 -0400 Received: from localhost (CONTENTS-VNDER-PRESSVRE.MIT.EDU [18.9.64.11]) (authenticated bits=0) (User authenticated as jfc@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p84FM5DA001371 for ; Sun, 4 Sep 2011 11:22:05 -0400 (EDT) Message-Id: <201109041522.p84FM5DA001371@outgoing.mit.edu> To: caml-list@inria.fr X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Sun, 04 Sep 2011 11:22:05 -0400 From: John Carr X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUixG6nois5PdnPYN5rQ4tPOzawODB6THpx iCWAMYrLJiU1J7MstUjfLoErY9aUBvaCpZwVk4/2MDcwbmbvYuTgkBAwkTjzuKKLkRPIFJO4 cG89G4gtJLCPUeLd99QuRi4g+wSjxLx1i5kgEjOYJH6uFAexeQWsJN4unc8IYosANc+af4UF xBYW0JXYuvwdC8RQXYmPi2aC7WIRUJV4MEsAJMwmICvxqL2LcQIj9wJGhlWMsim5Vbq5iZk5 xanJusXJiXl5qUW6xnq5mSV6qSmlmxhB/uSU5NvB+PWg0iFGAQ5GJR5eD+ckPyHWxLLiytxD jJIcTEqivI3Tkv2E+JLyUyozEosz4otKc1KLDzFKcDArifC61wLleFMSK6tSi/JhUtIcLEri vKt3OPgJCaQnlqRmp6YWpBbBZGU4OJQkeE2AYSskWJSanlqRlplTgpBm4uAEGc4DNLx6Isjw 4oLE3OLMdIj8KUZFKXFefZBmAZBERmkeXC8s3l4xigO9IsyrBFLFA4xVuO5XQIOZgAa7WiWB DC5JREhJNTDGNmqLLv9r9pjl/n6/R/fV5s3R/il8IyyXQafCPtDvb/OnFWfMf9rLfDnbXRhQ eIdBtLr6Sz6X7b2VTZKOnBH/uWz1zgqdNBYPPad4qOHElvD+MLOtwq19C7mykvnnbHLz2bQn P6TK8PuB31Iqs8Q/sJYEG9gaMK9aEvtOLFPlreTrojmJFUosxRmJhlrMRcWJALoMO4OSAgAA Subject: [Caml-list] Conditionally boxed 32 bit integers? I am working with a file format the contains 32 bit integers. I need to use int32 on 32 bit systems. I would like to use plain integers, unboxed and with native machine operations, on 64 bit systems. Is there any way to convince ocamlopt to choose between int and int32 representations _at compile time_? I could use first class modules to select implementations at runtime, which is not worth the code complexity and still requires an indirect function call to add numbers. I could conditionally compile different files depending on word size, which strikes me as an ugly and fragile solution. I want to be able to write "int32" and have that be compiled like an ordinary integer type if 32 bits and tag fit into a word, and as a boxed type otherwise. (The compiler could mask off excess precision if desired.) Is there a reason ocaml can't provide this? Another implementation would have each instance of an int32 or int64 be boxed or not depending on whether the value fits into a word. I don't know whether this would be faster or slower in practice. There is a tradeoff between allocations and conditional branches. --John Carr (jfc@mit.edu)