This is the mail archive of the gcc@gcc.gnu.org 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/15/07, Darryl Miles <darryl-mailinglists@netbauds.net> wrote:
> Andrew Haley wrote:
> > Darryl Miles writes:
> >  > Andrew Haley wrote:
> >  > I'm not aware of a small memory model until now, let alone that I maybe
> >  > actually using it already and that its already what I'm making an
> >  > inquiry about.
> >
> > Reading the gcc documentation would help you here.  Section 3.17.13,
> > Intel 386 and AMD x86-64 Options.
>
> Its just a shame that section number related to a different CPU
> depending upon which version of GCCs documentation you are looking at.
>
> Ah found it for those following:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
>
>
> I think the main point I was getting at was this ABI would run within a
> 32bit address space at runtime (just like 32bit code does).  It would be
> possible for it to see and use the 64bit version of kernel calls
> however, even if the values for stuff like mmap() always returned within
> the bottom 4Gb address space.
>
> The purpose of the new ABI was to make use of AMD64/EMT64 features
> knowing there is a runtime guarantee they are available.  This would
> untimely end up with an entire distribution being recompiled for this
> ABI to see the speed benefits (if there are any to be had?).

The idea is not exactly new, the main complication is that it would need
hacking both the gcc (and glibc) side and the kernel syscall interface.  The
32bit compatibility entries cannot be used if you want to align long long and
double naturally (which you certainly want, for performance reasons).

Richard.


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