caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Sven LUTHER <luther@dpt-info.u-strasbg.fr>
To: Xavier Leroy <xavier.leroy@inria.fr>
Cc: Sven LUTHER <luther@dpt-info.u-strasbg.fr>,
	John Carr <jfc@MIT.EDU>, Alessandro Baretta <alex@baretta.com>,
	Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] Runtime overflow and what to do
Date: Sun, 13 Oct 2002 11:52:16 +0200	[thread overview]
Message-ID: <20021013095216.GA1949@iliana> (raw)
In-Reply-To: <20021013113130.L13771@pauillac.inria.fr>

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


  reply	other threads:[~2002-10-13  9:42 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-10 15:01 Scott J,
2002-10-10 15:07 ` Maxence Guesdon
2002-10-10 15:11 ` Maxence Guesdon
2002-10-10 15:21 ` Luc Maranget
2002-10-10 18:13   ` Sven LUTHER
2002-10-10 18:57     ` Xavier Leroy
2002-10-10 22:17       ` Scott J,
2002-10-11  8:00         ` Sven LUTHER
2002-10-11 10:16         ` Alessandro Baretta
2002-10-12 16:13           ` John Carr
2002-10-12 16:58             ` Sven LUTHER
2002-10-12 17:12               ` John Prevost
2002-10-13  9:31               ` Xavier Leroy
2002-10-13  9:52                 ` Sven LUTHER [this message]
2002-10-13  9:57                   ` Xavier Leroy
2002-10-13 10:15                     ` Sven LUTHER
2002-10-13 13:25                   ` John Carr
2002-10-13  9:28             ` Xavier Leroy
2002-10-14  0:56               ` Chris Hecker
2002-10-14  9:46                 ` Jacques Garrigue
2002-10-14 11:02                   ` Scott J,
2002-10-14 14:05                   ` Tim Freeman
2002-10-14 15:32                     ` Stefano Zacchiroli
2002-10-14 16:12                       ` Alain Frisch
2002-10-14 16:49                   ` [Caml-list] new ocaml switches (was Re: Runtime overflow and what to do) Chris Hecker
2002-10-13  9:25         ` [Caml-list] Runtime overflow and what to do Xavier Leroy
2002-10-13 10:04           ` Daniel de Rauglaudre
2002-10-13 10:29             ` Pierre Weis
2002-10-13 10:47               ` Daniel de Rauglaudre
2002-10-13 12:38                 ` Pierre Weis
2002-10-13 16:14               ` Xavier Leroy
2002-10-13 17:06                 ` Michel Quercia
2002-10-15 19:15                 ` Pierre Weis
2002-10-15 19:25                   ` Xavier Leroy
2002-10-16  8:24                     ` Pierre Weis
2002-10-13 10:19           ` Pierre Weis
2002-10-11  8:02       ` Sven LUTHER
2002-10-11  6:42 ` Florian Hars

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=20021013095216.GA1949@iliana \
    --to=luther@dpt-info.u-strasbg.fr \
    --cc=alex@baretta.com \
    --cc=caml-list@inria.fr \
    --cc=jfc@MIT.EDU \
    --cc=xavier.leroy@inria.fr \
    /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).