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 WAA20875 for caml-red; Sun, 21 Jan 2001 22:23:19 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA21911 for ; Sun, 21 Jan 2001 11:45:40 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f0LAjcv22645; Sun, 21 Jan 2001 11:45:38 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA14184; Sun, 21 Jan 2001 11:45:38 +0100 (MET) Date: Sun, 21 Jan 2001 11:45:38 +0100 From: Xavier Leroy To: Norman Ramsey Cc: caml-list@inria.fr Subject: Re: more on nativeint interface Message-ID: <20010121114538.C13901@pauillac.inria.fr> References: <200101181907.OAA28875@labrador.eecs.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200101181907.OAA28875@labrador.eecs.harvard.edu>; from nr@eecs.harvard.edu on Thu, Jan 18, 2001 at 02:07:52PM -0500 Sender: weis@pauillac.inria.fr > It would be useful to have > val width : int (* number of bits in an integer of type nativeint *) > so that, for example, I could do sign extension by suitable shifting. Good idea. Actually, this information is already available in Sys.word_size, but repeating it in Nativeint could help. > let sx k n = N.shift_right (N.shift_left n (width-k)) (width-k) > (* sign-extend the least significant k bits of integer n *) > > let sx13 = sx 13 > > Unfortunately, the code that the ocamlopt produces for this function > (on x86) is pretty bad. > > I can get significantly better code by using this source: > > let width=32 > let sx13b n = N.shift_right (N.shift_left n (width-13)) (width-13) > > But of course this code isn't portable. > > Is there anything I can do to get the compiler to do a better job with > nativeint? The compiler support for int32/int64/nativeint in OCaml 3.00 was pretty minimal; the next release will have more optimizations, especially w.r.t. unboxing. (Constant propagation for these integer types would be nice too, except that the compiler must be very careful with nativeint, since the compiler can run on a machine with a different word size than the machine running the final program.) Still, I don't think variable-sized shifts will improve. One trick you can play is specialize the function at link-time: let sx13b = match Sys.word_size with 32 -> (fun n -> N.shift_right (N.shift_left n (32-13)) (32-13)) | 64 -> (fun n -> N.shift_right (N.shift_left n (64-13)) (64-13)) | _ -> assert false The shifts will be compiled better, however sx13b is no longer a "known function", so calls to it will always be indirect, i.e. slower. So this may not be a performance win after all. - Xavier Leroy