This is the mail archive of the
mailing list for the GCC project.
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
- From: "Seongbae Park (박성배, 朴成培)" <seongbae dot park at gmail dot com>
- To: "Darryl L. Miles" <darryl-mailinglists at netbauds dot net>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 16 Oct 2007 23:49:33 -0700
- Subject: Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
- References: <4712CE64.firstname.lastname@example.org>
On 10/14/07, Darryl L. Miles <email@example.com> wrote:
> 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
> 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.
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, http://seongbae.blogspot.com"