caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Ville-Pertti Keinonen <will@exomi.com>
To: David Brown <caml@davidb.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, caml-list@inria.fr
Subject: Re: [Caml-list] Re: 32- and 64-bit performance
Date: Sun, 03 Apr 2005 13:01:42 +0300	[thread overview]
Message-ID: <424FBF06.6060100@exomi.com> (raw)
In-Reply-To: <opsomhiln2ho2unb@a64.davidb.org>

David Brown wrote:

> On Sat, 02 Apr 2005 15:23:21 -0500, Stefan Monnier  
> <monnier@iro.umontreal.ca> wrote:
>
>> Under Alpha they called it "taso".  Mostly used for compatibility 
>> with  apps
>> that were assuming the size of ptrs is the same as the size of int: 
>> it  just
>> made the C library use only the bottom 4GB of the address space such 
>> that
>> the compiler could use only 32bit to store pointer values.
>
>
> The default mode in gcc for amd64 is almost this (-mcmodel=small).  
> It  assumes pointers live in the lower 2GB of address space, but 
> 'sizeof (void  *)' is still 8.  I'm not sure why the small model 
> doesn't use 32-bit  pointers.

I think you've misunderstood the gcc documentation, -mcmodel=small is 
not really comparable to the -xtaso compiler option on the Alpha at all.

-mcmodel=small handles pointers as fully 64-bit, with the exception of 
loading constant pointers to symbols in the text and data segments.  
Programs compiled using this mode are entirely capable of addressing the 
entire address space.  Memory allocations, shared libraries, memory 
mapped files and stack can and do live outside the 2GB range and 
pointers to them work just fine.

The reason for this mode is to avoid having to store and load full 
64-bit constant pointers in the binary.  It really only affects 
relocations for particular types of address loads.  You still get full 
64-bit relocations e.g. if you initialize a global pointer to a constant 
symbol.


      reply	other threads:[~2005-04-03 10:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-30  2:40 Jon Harrop
2005-03-30  7:46 ` [Caml-list] " Alex Baretta
2005-03-30  8:00   ` Ville-Pertti Keinonen
2005-03-30  8:41     ` Alex Baretta
2005-03-30  9:01       ` Ville-Pertti Keinonen
2005-03-30 12:53         ` Jon Harrop
2005-03-30 14:34           ` Ville-Pertti Keinonen
2005-03-30  8:10   ` Robert Roessler
2005-03-30  8:11   ` Alexander S. Usov
2005-03-30 13:46 ` Eijiro Sumii
2005-03-31 13:42   ` Jon Harrop
2005-03-31 15:05 ` Stefan Monnier
2005-03-31 18:40   ` [Caml-list] " Jon Harrop
2005-03-31 22:41     ` Richard Jones
2005-04-02 20:23     ` Stefan Monnier
2005-04-02 20:50       ` [Caml-list] " David Brown
2005-04-03 10:01         ` Ville-Pertti Keinonen [this message]

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=424FBF06.6060100@exomi.com \
    --to=will@exomi.com \
    --cc=caml-list@inria.fr \
    --cc=caml@davidb.org \
    --cc=monnier@iro.umontreal.ca \
    /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).