Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
more on nativeint interface
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-01-21 (21:23)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: more on nativeint interface
> 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