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
Objective Caml 3.00 released
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-04-28 (10:19)
From: Xavier Leroy <xleroy@p...>
Subject: Re: what does "32-bit integer" mean?
> > (I think you just won the first prize for most vacuous question asked on
> > this mailing list.)
> 	Thanks :-(

My apologies for the sarcasm; I know I shouldn't have done it, but I just
couldn't resist :-)

> In particular, since ocaml does not provide any unsigned integers,
> it is exposed to the mal-specified signed operations of the C
> compiler. I do NOT like this. I would rather that the
> ocaml team provide a mathematical definition, and MAKE
> the implementation work that way on all target machines
> independently of what C does.

We could easily specify Caml's integers as twos complement, with
division that rounds towards zero, signed modulus, etc, etc --- all the
guarantees that C doesn't give us ---, then check those properties
during configuration and refuse to compile OCaml on machines that do
not meet those properties.  Given that all modern machines meet them,
that would not be a limitation in practice.

The other option (emulate twos complement / signed modulus / etc) on
machines that do not provide them naturally is too much
work, and just pointless (since such machines no longer exist).

> 	I am a member of the C committee.
> The issues here are important and non-trivial.
> I write algorithms that depend on it :-) 
> I point them out only as a service to the ocaml community
> (myself included of course :-)

Thanks.  But as a member of the C committee, you could make all of us
(not just Caml users, but C programmers as well) a HUGE service
by pushing forward a C standard that fully specifies signed integer
arithmetic, e.g. like Java does.  (While you're at it, please standardize
IEEE floats as well.)

> 	I also do not use the bytecode interpreter.
> I'm interested in what the optimising compiler does.

The situation is much better on the native compiler front: since we
know exactly which processors are supported, we can actually guarantee
twos complement, division that rounds towards zero, signed modulus,
etc, etc, just because all the supported processors implement those

The limiting factor is the bytecode interpreter, at least as long as
we want it to work on any system with an ANSI-compliant C compiler.

- Xavier Leroy