This is the mail archive of the
mailing list for the GCC project.
Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
- From: "Darryl L. Miles" <darryl-mailinglists at netbauds dot net>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 15 Oct 2007 03:20:20 +0100
- Subject: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
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 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
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.