From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA18681; Sun, 13 Oct 2002 11:42:30 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 LAA18729 for ; Sun, 13 Oct 2002 11:42:29 +0200 (MET DST) Received: from mel-rto6.wanadoo.fr (smtp-out-6.wanadoo.fr [193.252.19.25]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g9D9gTD02284; Sun, 13 Oct 2002 11:42:29 +0200 (MET DST) Received: from mel-rta10.wanadoo.fr (193.252.19.193) by mel-rto6.wanadoo.fr (6.5.007) id 3DA24D4D0034D607; Sun, 13 Oct 2002 11:42:29 +0200 Received: from iliana (80.14.240.235) by mel-rta10.wanadoo.fr (6.5.007) id 3DA24C0A00362873; Sun, 13 Oct 2002 11:42:29 +0200 Received: from luther by iliana with local (Exim 3.36 #1 (Debian)) id 180fQ0-0000WQ-00; Sun, 13 Oct 2002 11:52:16 +0200 Date: Sun, 13 Oct 2002 11:52:16 +0200 To: Xavier Leroy Cc: Sven LUTHER , John Carr , Alessandro Baretta , Ocaml Subject: Re: [Caml-list] Runtime overflow and what to do Message-ID: <20021013095216.GA1949@iliana> References: <3DA6A4ED.5050700@baretta.com> <200210121613.MAA27433@psi-phi.mit.edu> <20021012165831.GA4700@iliana> <20021013113130.L13771@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021013113130.L13771@pauillac.inria.fr> User-Agent: Mutt/1.4i From: Sven LUTHER Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, Oct 13, 2002 at 11:31:30AM +0200, Xavier Leroy wrote: > > BTW, i compile the sparc debian package on a sparc64 box which > > advertizes as a sparc box. Will i get access to the 64 bit integers in > > this case or not ? > > The short answer is: it depends on the C compiler. Caml integers > correspond to the C "long int" type, with one bit reserved for GC > purposes. So, if the C compiler maps "long int" to 64-bit integers, > you get 63-bit Caml ints; if it chooses 32-bit integers for "long int", > you get 31-bit Caml ints. Often, this can be controlled via flags to > the C compiler. Ok, ... Which would be the relevant flags ? i get (from the build log) : ... Checking the sizes of integers and pointers... OK, this is a regular 32 bit architecture. 64-bit "long long" integer type found (printf with "%ll"). This is a big-endian architecture. Doubles must be doubleword-aligned. 64-bit integers must be doubleword-aligned. ... Configuration for the bytecode compiler: C compiler used........... gcc options for compiling..... -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -D_REENTRANT options for linking....... -Wl,-E -lm -ldl -lcurses -lpthread shared libraries are supported options for compiling..... -fPIC -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -D_REENTRANT command for building...... gcc -shared -o lib.so -Wl,-rpath,/a/path objs So i suppose this is not using 64 bit mode. More importantly, i suppose code compiled in this fashion for 64 bit sparcs will not build on 32 bit sparc boxes, if these kind of boxes are still available anyway. > The above is for the bytecode interpreter. For the native-code > compiler, the current Sparc code emitter mandates 32-bit integers. Would it be much work to build a 64-bit integers target ? Friendly, Sven Luther ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners