This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?

Darryl L. Miles writes:
 > On SPARC there is an ABI that is V8+ which allows the linking (and
 > mixing) of V8 ABI but makes uses of features of 64bit UltraSparc
 > CPUs (that were not available in the older 32bit only CPUs).
 > Admittedly looking at the way this works it could be said that Sun
 > had a certain about of forward thinking when they developed their
 > 32bit ABI (this is not true of the 32bit Intel IA32 ABIs that
 > exist).
 > Are there any plans for a plan a new Intel IA32 ABI that is
 > designed solely to run on 64bit capable Intel IA32 CPUs (that
 > support EMT64) ?  Userspace would have 32bit memory addressing, but
 > access to more registers, better function call conventions, etc...

This doesn't sound very different from the small memory model.  With
the small model, the program and its symbols must be linked in the
lower 2 GB of the address space, but pointers are still 64 bits.  This
is the default model for gcc on GNU/Linux.  It would be possible in
theory to have a `smaller' memory model that only allowed 32-bit
pointers, I suppose.

 > My own anecdotal evidence is that I've been using a x86_64
 > distribution (with dual 64bit and 32bit runtime support) for a few
 > years now and have found performance to be lacking in my two
 > largest footprint applications (my browser and my development IDE
 > totaling 5Gb of footprint between them).  I recently converted both
 > these applications from their 64bit versions to 32bit (they are the
 > only 32bit applications running) and the overall interactive
 > performance has improved considerably possibly due to the reduced
 > memory footprint alone, a 4.5 Gb footprint 64bit application is
 > equivalent to a 2 Gb footprint 32bit application in these
 > application domains.

This is amazing!  There is no way that going from the ia32 to
(presumably) the x86_64 small model should more than double memory
consumption.  Where has all that memory gone?  I think some analysis
of memory consumption is needed.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]