From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA04422 for caml-redist; Fri, 28 Apr 2000 12:08:22 +0200 (MET DST) 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 EAA07381; Fri, 28 Apr 2000 04:07:06 +0200 (MET DST) Received: from localhost.localdomain (ike225.zip.com.au [210.23.146.225]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id EAA20622; Fri, 28 Apr 2000 04:07:01 +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 MAA06558; Fri, 28 Apr 2000 12:07:41 +1000 Sender: weis Message-ID: <3908F26D.98C27C2E@maxtal.com.au> Date: Fri, 28 Apr 2000 12:07:41 +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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Xavier Leroy wrote: > (I think you just won the first prize for most vacuous question asked on > this mailing list.) Thanks :-( > > It is _necessary_ to say something like > > 'implements an integer with 32 bit twos complement > > representation' for either of these statements to be meaningful, > > that is, to establish a mapping between an array of 32 bits, > > and an integral value. > > Ah, twos complement and ones complement -- comp.lang.c 's favorite > flame war. (I know you love flame wars, but are you sure we should > have this one here? I am not interested in wars or flame wars. I am sure we should have this discussion, however. > Caml integers are C integers in (slight) disguise -- by virtue of the > Caml bytecode interpreter being written in ANSI C. C integers are > machine integers in (slight) disguise. The ANSI C reference explains > what can be assumed on integers and what is machine-dependent. Yes, > bitwise operations expose the difference between twos complement and > ones complement. So what? This would be a flaw in the ocaml language specification. > At any rate, no ones complement computer have been produced in the last > 20 years, so it should be safe to assume twos complement if you need > to make that assumption. I'm not interested in 'should be safe' as much as specified language semantics. In this case, you are refering to the 'C specification', but this is not done in the manual. You also do not say WHICH C specification, C90 or C9X. The semantics I refer to are tightened up a bit in C9X. > This reminds me of a nice compiler book from the late 60s, whose title > is something like "Compilation for digital computers". Presumably, in > these days, one had to specify that one's computer was digital, not > analog. Now we don't bother. 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 :-) 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. This is the course taken by Python. I also do not use the bytecode interpreter. I'm interested in what the optimising compiler does. -- 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