From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA11586 for caml-red; Sun, 14 Jan 2001 21:23:34 +0100 (MET) 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 UAA08152 for ; Fri, 12 Jan 2001 20:54:26 +0100 (MET) Received: from thresher.corp.xpsystems.com (proxy.xpsystems.com [207.171.47.2]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f0CJsLL08251 for ; Fri, 12 Jan 2001 20:54:25 +0100 (MET) Received: by thresher.corp.xpsystems.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 11:54:26 -0800 Message-ID: From: Brent Fulgham To: Dave Berry Cc: caml-list@inria.fr Subject: RE: questions about costs of nativeint vs int Date: Fri, 12 Jan 2001 11:53:34 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: weis@pauillac.inria.fr > Do you have any plans to implement unboxed native integers? > There's an interesting paper on the Caml site discussing the performance issues of boxed/unboxed values. From a performance standpoint I believe it indicated boxed values were a better tradeoff (between performance/flexibility), though the C integration issues you mention below were not (IIRC) discussed. > I would really have liked to see this happen, because it > would have made integration with C both easier and more efficient. > Couldn't a wrapper generator of some kind make this less problematic? For instance, the MzScheme implementation provides various C Macros and other tools to get at the boxed values: int scheme_get_int_val(Scheme_Object* v); And some predicates to decide what kind of object you are dealing with: int SCHEME_INTP(Scheme_Object* v); // Returns true/false. SWIG can be used to auto-generate interface code using these routines to provide a C/Scheme bridge. This should be possible in OCaml as well. -Brent