From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id BBBA1BC48 for ; Sun, 3 Apr 2005 12:01:54 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j33A1s3m031651 for ; Sun, 3 Apr 2005 12:01:54 +0200 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 MAA24279 for ; Sun, 3 Apr 2005 12:01:53 +0200 (MET DST) Received: from will.iki.fi (will.iki.fi [217.169.64.20]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j33A1r6J014494 for ; Sun, 3 Apr 2005 12:01:53 +0200 Received: from [192.168.1.204] (ZMCXLI.dsl.saunalahti.fi [85.76.70.242]) by will.iki.fi (Postfix) with ESMTP id B38C8CD; Sun, 3 Apr 2005 13:01:52 +0300 (EEST) Message-ID: <424FBF06.6060100@exomi.com> Date: Sun, 03 Apr 2005 13:01:42 +0300 From: Ville-Pertti Keinonen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050401) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Brown Cc: Stefan Monnier , caml-list@inria.fr Subject: Re: [Caml-list] Re: 32- and 64-bit performance References: <200503300340.15874.jon@ffconsultancy.com> <871x9vzwk7.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> <200503311940.18701.jon@ffconsultancy.com> <87zmwh3p8m.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 424FBF12.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 424FBF11.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 umontreal:01 compiler:01 pointer:01 gcc:01 pointers:01 model:01 pointers:01 gcc:01 compiler:01 allocations:01 stack:01 binary:01 pointer:01 wrote:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: David Brown wrote: > On Sat, 02 Apr 2005 15:23:21 -0500, Stefan Monnier > 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.