Browse thread
32- and 64-bit performance
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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.