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+ ?

On 10/14/07, Darryl L. Miles <> wrote:
> Hello,
> 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).

Sun didn't have much forward thinking with their 32-bit ABI.
It's just that their 32-bit ISA was relatively amenable
to 64-bit extension with 32-bit ABI compatibility,
which can not be said for IA32.

> 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 would be aimed to replace the existing i386/i686 ABIs on the
> desktop and would not be looking to maintain backward compatibility
> directly.
> 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.
> Maybe someone knows of a white paper published to find out if the
> implications and benefit a movement in this direction would mean.  Maybe
> just using the existing 64bit ABI with 32bit void pointers (and long's)
> is as good a specification as any.
> RFCs,
> Darryl

More appropriate comparison is probably against MIPS,
with their two 32-bit ABIs (O32 and N32 ABI).
Essentially you're asking for N32 equivalent.

My bet is that most people simply don't care enough about
the performance differential.
#pragma ident "Seongbae Park, compiler,";

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