caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Norman Ramsey <nr@eecs.harvard.edu>
Cc: caml-list@inria.fr
Subject: Re: more on nativeint interface
Date: Sun, 21 Jan 2001 11:45:38 +0100	[thread overview]
Message-ID: <20010121114538.C13901@pauillac.inria.fr> (raw)
In-Reply-To: <200101181907.OAA28875@labrador.eecs.harvard.edu>; from nr@eecs.harvard.edu on Thu, Jan 18, 2001 at 02:07:52PM -0500

> 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



      reply	other threads:[~2001-01-21 21:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-18 19:07 Norman Ramsey
2001-01-21 10:45 ` Xavier Leroy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010121114538.C13901@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=nr@eecs.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).