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 TAA05027 for caml-redist@pauillac.inria.fr; Mon, 1 May 2000 19:08:12 +0200 (MET DST) Resent-Message-Id: <200005011708.TAA05027@pauillac.inria.fr> 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 LAA23903; Mon, 1 May 2000 11:46:18 +0200 (MET DST) Received: from localhost.localdomain (cartman33.zip.com.au [61.8.20.161]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id LAA19719; Mon, 1 May 2000 11:46:08 +0200 (MET DST) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id JAA10241; Sat, 29 Apr 2000 09:24:37 +1000 Sender: root@localhost.localdomain Message-ID: <390A1DB1.37472203@maxtal.com.au> Date: Sat, 29 Apr 2000 09:24:33 +1000 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Xavier Leroy CC: Max Skaller , caml-list@pauillac.inria.fr Subject: Re: what does "32-bit integer" mean? References: <20000425152615.25958@pauillac.inria.fr> <39069410.FC5F5DBB@in.ot.com.au> <20000427101749.40550@pauillac.inria.fr> <3908F26D.98C27C2E@maxtal.com.au> <20000428103509.02540@pauillac.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: weis@pauillac.inria.fr Resent-Date: Mon, 1 May 2000 19:08:12 +0200 Resent-To: caml-redist@pauillac.inria.fr Xavier Leroy wrote: > 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 ---, That would be good I think. > 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. Given that it is usually possible to implement the desired semantics, such a limitation could also be removed with some additional effort if necessary. > > 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.) The C9X rules are firmer but not yet deterministic. > 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 > properties. > > 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. That makes sense. However, it may make sense to specify the desired semantics anyway, and state that the bytecode interpreter is not conformant on certain systems. By the way, I think for 'native' int, the semantics can be loose: the idea being to 'do what the machine does', the purpose here is already machine specific. Perhaps by way of explanation: I feel that the ocaml team and myself share a goal: to be able to write code about which various properties are easily deduced. Reasoning about bitwise operations use together with integral ones on special 'portable register' types such as int32 would be enhanced by a strictly deterministic semantics. So I mentioned this 'flaw' in the manual not to whinge, but to show how easily a common goal might be met. Many applications needing to perform encoding/decoding functions would benefit I think, from knowing either that they're 'portable across all ocaml platforms' or at least having a rule to know on _which_ the language will model desired behaviour. In particular, many operations are easily specified with unsigned types like 'uint32' which can only be translated to signed types with a deterministic semantics. From what you have said, all existing, known, ocaml ports meet the twos complement specification anyhow, so not much is lost by making that a requirement. :-) -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net