On 10/15/07, Darryl Miles <[EMAIL PROTECTED]> 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.
