Version française
Home     About     Download     Resources     Contact us    
Browse thread
32- and 64-bit performance
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Ville-Pertti Keinonen <will@e...>
Subject: Re: [Caml-list] Re: 32- and 64-bit performance
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.