Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
Darryl L. Miles writes: > > 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 doesn't sound very different from the small memory model. With the small model, the program and its symbols must be linked in the lower 2 GB of the address space, but pointers are still 64 bits. This is the default model for gcc on GNU/Linux. It would be possible in theory to have a `smaller' memory model that only allowed 32-bit pointers, I suppose. > 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. This is amazing! There is no way that going from the ia32 to (presumably) the x86_64 small model should more than double memory consumption. Where has all that memory gone? I think some analysis of memory consumption is needed. Andrew.
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
Andrew Haley wrote: This doesn't sound very different from the small memory model. With the small model, the program and its symbols must be linked in the lower 2 GB of the address space, but pointers are still 64 bits. This is the default model for gcc on GNU/Linux. It would be possible in theory to have a `smaller' memory model that only allowed 32-bit pointers, I suppose. Small memory model ? I don't understand the point of the "small memory model" nor can I substantiate anything you are saying from the littlepickcloud, LOL what a domain. 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. I wonder if you are aware of the differences between SPARC V8 and V8+ ABIs, how they are both 32bit runtime memory model, using 32bit pointers, but the V8+ only works on a 64bit capable CPU and on a kernel that supports both 32 and 64bit userspace and is itself 64bit internally ? Yes maybe there is a restriction in the ELF format on the maximum executable size but linking has little to do with the issue of improving performance via better linkage ABI rules. Passing function arguments by registers [64bit] verses by stack [32bit]. The problem was not that I need to create a final executable file near the 2Gb limit but one of what benefits can be got from newer 64bit capable IA32 cpus from the extra registers available being used to run 32bit code running in a 32bit address space. One of the issues is that pointer storage is 8 bytes, so all structure sizes increased, so more memory is needed. So pointer intensive applications have poor memory footprints as 64bit application and most desktop applications do not require more than 3Gb of exec+heap+stacks+etc. I also believe code size will reduce too, due to less code needed to manage passing arguments via the stack and better code generation. This is amazing! There is no way that going from the ia32 to (presumably) the x86_64 small model should more than double memory consumption. Where has all that memory gone? I think some analysis of memory consumption is needed. I presume all the memory is eaten up dealing with 64bit issues both Mozilla (using XPCom) and Eclipse (running in a Java JVM) make extensive use of pointers. Although Mozilla is a little harder for me to measure comparatively but I've never gotten it over 1Gb Resident Set Size (with no swap in use). Darryl
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
Darryl Miles writes: > Andrew Haley wrote: > > This doesn't sound very different from the small memory model. With > > the small model, the program and its symbols must be linked in the > > lower 2 GB of the address space, but pointers are still 64 bits. This > > is the default model for gcc on GNU/Linux. It would be possible in > > theory to have a `smaller' memory model that only allowed 32-bit > > pointers, I suppose. > > Small memory model ? I don't understand the point of the "small memory > model" nor can I substantiate anything you are saying from the > littlepickcloud, LOL what a domain. > > 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. > > This is amazing! There is no way that going from the ia32 to > > (presumably) the x86_64 small model should more than double > > memory consumption. Where has all that memory gone? I think > > some analysis of memory consumption is needed. > > I presume all the memory is eaten up dealing with 64bit issues both > Mozilla (using XPCom) and Eclipse (running in a Java JVM) make > extensive use of pointers. Although Mozilla is a little harder for > me to measure comparatively but I've never gotten it over 1Gb > Resident Set Size (with no swap in use). That's interesting. I certainly have seen some increase in memory consumption goinf from 32-bit to 64-bit applications on x86_64, but the fact that in your case it more than doubles is come cause for concern. Even if pointers were 50% of the allocated memory pool, which is a pretty extreme assumption, that would only increase memory use by 50%. In your case, however, memory use has increased by 150%. This needs explanation. Andrew.
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
Andrew Haley <[EMAIL PROTECTED]> writes: > > Reading the gcc documentation would help you here. Section 3.17.13, > Intel 386 and AMD x86-64 Options. > > > > This is amazing! There is no way that going from the ia32 to > > > (presumably) the x86_64 small model should more than double > > > memory consumption. Where has all that memory gone? I think > > > some analysis of memory consumption is needed. > > > > I presume all the memory is eaten up dealing with 64bit issues both > > Mozilla (using XPCom) and Eclipse (running in a Java JVM) make > > extensive use of pointers. Although Mozilla is a little harder for > > me to measure comparatively but I've never gotten it over 1Gb > > Resident Set Size (with no swap in use). > > That's interesting. I certainly have seen some increase in memory > consumption goinf from 32-bit to 64-bit applications on x86_64, but > the fact that in your case it more than doubles is come cause for > concern. Even if pointers were 50% of the allocated memory pool, > which is a pretty extreme assumption, that would only increase memory > use by 50%. Sometimes memory doublings are also seen from "long". > In your case, however, memory use has increased by 150%. > This needs explanation. Maybe he is just mismeasuring it. e.g. text mappings like shared libraries on x86-64 are padded out to 1MB because that is the ELF page size. But the shared libraries don't actually need that much space. Some tools get confused by this though. Of course text mappings should normally also only be a smaller part of his address space. In general it is pretty complicated to measure real user space memory in complicated applications accurately because it is difficult to figure out which pages are shared between processes and which not. But maybe several such measurement errors add up in this case. -Andi
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
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?). > I presume all the memory is eaten up dealing with 64bit issues both > Mozilla (using XPCom) and Eclipse (running in a Java JVM) make > extensive use of pointers. Although Mozilla is a little harder for > me to measure comparatively but I've never gotten it over 1Gb > Resident Set Size (with no swap in use). That's interesting. I certainly have seen some increase in memory consumption goinf from 32-bit to 64-bit applications on x86_64, but the fact that in your case it more than doubles is come cause for concern. Even if pointers were 50% of the allocated memory pool, which is a pretty extreme assumption, that would only increase memory use by 50%. In your case, however, memory use has increased by 150%. This needs explanation. There is a possibly of extra padding alignment issues (so there maybe benefits within these applications to reordering stuff to account for 64bit alignment rules). There is increased stack size needs and increased stack usage in both these apps which make use of many threads. I'm not sure if mmap() files that are also paged in the RSS count, as I guess in the 32bit runtime model the strategy for using mmap() to access files maybe different to 64bit. For example I had to increase the open fd limit on Eclipse to 2048 since I could easily make it break the default 1024 limit from doing a complete workspace rebuild. Most of these open files are due to mmap()s. Maybe there are other reasons I can't think of right now. Thats a job for someone, ensure enough information is emitted in the -g3 debug information going into the executable to reconstruct all structures/datatypes so that a tool could extract the amount of wasted padding and calculate the potential for savings to be made through reordering structure members and the like. Darryl
Can't bootstrap gcc-4.2.2 with Ada on cygwin: Bootstrap comparison failure! ./ada/exp_aggr.o differs
Windows XP/SP2 cygwin on pentium4 single i686: binutils 20060817-1 bison2.3-1 cygwin 1.5.24-2 (with Dave Korn's stdio patch for newlib) dejagnu 20021217-2 expect 20030128-1 gcc 3.4.4-3 gcc-ada 3.4.4-3 gcc-g++ 3.4.4-3 gmp 4.2.1-1 make 3.81-1 mpfr 2.2.1-1 tcltk20060202-1 w32api 3.10-1 LAST_UPDATED: Obtained from SVN: tags/gcc_4_2_2_release revision 129115 configure: --disable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --disable-libgcj --with-system-zlib --enable-threads-posix --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang This is just a simple reminder to all of us... make[3]: Leaving directory `/usr/local/src/branch/objdir' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1obj-checksum.o differs warning: ./cc1objplus-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./libgcc/_chkstk.o differs Bootstrap comparison failure! ./ada/exp_aggr.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/usr/local/src/branch/objdir' -- Cheers, /ChJ
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
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.
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
On Monday 15 October 2007 13:18, Darryl Miles wrote: > Yes maybe there is a restriction in the ELF format on the maximum > executable size but linking has little to do with the issue of improving > performance via better linkage ABI rules. Passing function arguments by > registers [64bit] verses by stack [32bit]. You cannot use 64bit registers in 32bit mode on x86_64. You also cannot use registers 8-15, neither general purpose nor XMM ones. They are simply not accessible at all. Can you elaborate what exactly can be significantly improved by new ABI? -- vda
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
On 10/15/07, Denys Vlasenko <[EMAIL PROTECTED]> wrote: > On Monday 15 October 2007 13:18, Darryl Miles wrote: > > Yes maybe there is a restriction in the ELF format on the maximum > > executable size but linking has little to do with the issue of improving > > performance via better linkage ABI rules. Passing function arguments by > > registers [64bit] verses by stack [32bit]. > > You cannot use 64bit registers in 32bit mode on x86_64. > You also cannot use registers 8-15, neither general purpose > nor XMM ones. They are simply not accessible at all. > > Can you elaborate what exactly can be significantly improved > by new ABI? The idea is to use 64bit mode but restrict (the used part of) pointers to 32bit (for example by zero-extending them or leaving the upper parts undefined). And of course make long 32bits again. This way you can do long long arithmetic using 64bit integer registers, have the extra registers available but save memory. Richard.
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
Richard Guenther wrote: 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). What does this mean? In 32-bit linux gcc, as currently set up, double alignment may be disabled by setting -Os or by -mpreferred-stack-boundary, but otherwise it is the default. The 64-bit int registers aren't available in 32-bit mode. Are you proposing a 64-bit mode with the same alignments as -Os sets in 32-bit mode?
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
"Richard Guenther" <[EMAIL PROTECTED]> writes: > > 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). double is already naturally aligned on i386, just long long isn't. -Andi
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
On Mon, Oct 15, 2007 at 08:00:53PM +0200, Andi Kleen wrote: > "Richard Guenther" <[EMAIL PROTECTED]> writes: > > > > 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). > > double is already naturally aligned on i386, just long long isn't. Actually no. In 32-bit mode, double is aligned on a 4 byte boundary, not an 8 byte boundary, unless you use -malign-double, which breaks the ABI. This has been a 'feature' of the original AT&T 386 System V ABI that Linux uses for 32-bit x86 processors. With the SCO mess, it may be hard to ever change that ABI -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
gcc 2.7.2 intrinsics
Hi! I am trying to define new ISA intructions for gcc 2.7.2. From what I fouind out using gcc intrinsics is the best way to go about this. However I am having trouble finding information on the intrinsics. And I am not particulary sure that 2.7.2 supports intrinsics anyway. I would appreciate any information on the intrinsics. Thank you. - Polina -- View this message in context: http://www.nabble.com/gcc-2.7.2-intrinsics-tf4630696.html#a13222815 Sent from the gcc - Dev mailing list archive at Nabble.com.
gcc-4.1-20071015 is now available
Snapshot gcc-4.1-20071015 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071015/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 129371 You'll find: gcc-4.1-20071015.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20071015.tar.bz2 C front end and core compiler gcc-ada-4.1-20071015.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20071015.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20071015.tar.bz2 C++ front end and runtime gcc-java-4.1-20071015.tar.bz2 Java front end and runtime gcc-objc-4.1-20071015.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20071015.tar.bz2The GCC testsuite Diffs from 4.1-20071008 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
> Actually no. In 32-bit mode, double is aligned on a 4 byte boundary, not an 8
> byte boundary, unless you use -malign-double, which breaks the ABI. This has
> been a 'feature' of the original AT&T 386 System V ABI that Linux uses for
> 32-bit x86 processors. With the SCO mess, it may be hard to ever change that
> ABI
My gcc doesn't agree with you (I actually checked before posting)
~> cat t.c
int main(void)
{
double x;
printf("%d\n", __alignof__(x));
return 0;
}
~> gcc -m32 -o t t.c
t.c: In function ‘main’:
t.c:5: warning: incompatible implicit declaration of built-in function ‘printf’
~> ./t
8
~>
-Andi
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
Andi Kleen <[EMAIL PROTECTED]> writes:
> My gcc doesn't agree with you (I actually checked before posting)
Your test is flawed.
$ cat align.c
#include
#include
struct x {
unsigned char a[1];
double b;
};
int
main (void)
{
printf ("%d\n", offsetof (struct x, b));
}
$ ./align
4
(long long has the same anomaly.)
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
gcc inline assembly
Hi! I would like to use the asm feature of the gcc compiler. I am not sure what backends the asm supports. Would it support any backend for which it was compiled? The reason I asked is because I cross-compiled gcc for the PISA architecture and I haven't been able to find any information on using asm to do inline PISA assembly. I would appreciate any information. Thank you. - Polina -- View this message in context: http://www.nabble.com/gcc-inline-assembly-tf4631623.html#a13225744 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: gcc inline assembly
polina <[EMAIL PROTECTED]> writes: > I would like to use the asm feature of the gcc compiler. I am not sure what > backends the asm supports. Would it support any backend for which it was > compiled? The reason I asked is because I cross-compiled gcc for the PISA > architecture and I haven't been able to find any information on using asm to > do inline PISA assembly. I would appreciate any information. Thank you. This question is not appropriate for the gcc@gcc.gnu.org mailing list. Please send any followups to [EMAIL PROTECTED] Thanks. The inline asm feature is supported by every backend. I don't know what PISA is--it sounds like you are using a port of gcc, not a standard FSF release. There is nothing wrong with that, but it does mean that we can't give you any information on how to use it. Ian
