Re: calculation of pi
On 11/05/2012 12:26 PM, David Brown wrote: On 05/11/2012 11:33, Mischa Baars wrote: On 11/05/2012 05:55 AM, Ian Lance Taylor wrote: On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars mjbaars1...@gmail.com wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: There is no original. The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. An ABI is by definition processor specific. The placement of argument values is chosen based on runtime efficiency, not on any other sort of logic. On x86_64, 32-bit and 64-bit float values can be passed directly in registers, as the x86_64 has efficient 32-bit and 64-bit floating point registers. The x86_64 does not have floating point registers that can efficiently store floating point values with more than 64 bits, so those values are not passed in floating point registers. To make any other choice would cost runtime efficiency, which is the only logic that matters. Ian Hi Ian, Here I have attached the code that proves that you are wrong, the 64-bit code gets slower and not faster while passing arguments in 'xmm0' when loading arguments in the floating point core for processing, i.e. transcendental functions like 'fsin' which can't be done using 'sse' instructions. For the extended real numerical type, the argument cannot even be passed in 'xmm0' since there are no 'sse' instructions for extended real numbers, which makes the passing of arguments in 64-bit mode very inconsistent as you can see. Regards, Mischa. Hi, I think you are still misunderstanding the situation here. Floating point arguments are not passed in the xmm registers because Ian thinks it's faster. They are passed in the xmm registers because that is the ABI that was agreed on long ago by a group of experienced experts involved in the design of the processor (the 64-bit AMD processors, since they pre-dated Intel's 64-bit x86 chips), compiler design, and operating system design (since it is the ABI for 64-bit x86 Linux we are discussing). It is quite possible that Ian was part of that group - he is an experienced expert - but it was not his decision. And it is /not/ going to change. The ABI is fixed - you have to live with it. I'm sure there are many aspects of the 32-bit x86 ABI that people would like to change, since it was fixed in stone before features like xmm registers were part of the x86 cpus. But that doesn't happen - you have to keep the ABI consistent. For purely internal code - static functions without external linkage - the compiler can use whatever calling conventions it wants. If you think that such calls could be done better, then that can be discussed or filed as missed optimisation bug reports. In the particular case of passing floating point arguments, of course, the extra step needed to move data from an xmm register onto the stack for the fsin code is totally negligible. The great majority of floating point operations /are/ handled by SSE instructions, since operations such as load, store, register move, and basic arithmetic outweigh the use of transcendental functions by many orders of magnitude. You do not change the ABI used by an entire operating system to shave a few clock cycles off an unusual piece of test code to calculate pi. mvh., David Then it will probably will not hurt you either when you run this 'unusual piece of test code' on your 'entire operating system' :) Mischa. 2012110501 - division by zero.tar.bz2 Description: application/bzip
Re: calculation of pi
On 11/05/2012 05:55 AM, Ian Lance Taylor wrote: On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars mjbaars1...@gmail.com wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: There is no original. The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. An ABI is by definition processor specific. The placement of argument values is chosen based on runtime efficiency, not on any other sort of logic. On x86_64, 32-bit and 64-bit float values can be passed directly in registers, as the x86_64 has efficient 32-bit and 64-bit floating point registers. The x86_64 does not have floating point registers that can efficiently store floating point values with more than 64 bits, so those values are not passed in floating point registers. To make any other choice would cost runtime efficiency, which is the only logic that matters. Ian Hi Ian, Here I have attached the code that proves that you are wrong, the 64-bit code gets slower and not faster while passing arguments in 'xmm0' when loading arguments in the floating point core for processing, i.e. transcendental functions like 'fsin' which can't be done using 'sse' instructions. For the extended real numerical type, the argument cannot even be passed in 'xmm0' since there are no 'sse' instructions for extended real numbers, which makes the passing of arguments in 64-bit mode very inconsistent as you can see. Regards, Mischa. 2012110500 - arguments.tar.bz2 Description: application/bzip
Re: calculation of pi
On 05/11/2012 11:33, Mischa Baars wrote: On 11/05/2012 05:55 AM, Ian Lance Taylor wrote: On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars mjbaars1...@gmail.com wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: There is no original. The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. An ABI is by definition processor specific. The placement of argument values is chosen based on runtime efficiency, not on any other sort of logic. On x86_64, 32-bit and 64-bit float values can be passed directly in registers, as the x86_64 has efficient 32-bit and 64-bit floating point registers. The x86_64 does not have floating point registers that can efficiently store floating point values with more than 64 bits, so those values are not passed in floating point registers. To make any other choice would cost runtime efficiency, which is the only logic that matters. Ian Hi Ian, Here I have attached the code that proves that you are wrong, the 64-bit code gets slower and not faster while passing arguments in 'xmm0' when loading arguments in the floating point core for processing, i.e. transcendental functions like 'fsin' which can't be done using 'sse' instructions. For the extended real numerical type, the argument cannot even be passed in 'xmm0' since there are no 'sse' instructions for extended real numbers, which makes the passing of arguments in 64-bit mode very inconsistent as you can see. Regards, Mischa. Hi, I think you are still misunderstanding the situation here. Floating point arguments are not passed in the xmm registers because Ian thinks it's faster. They are passed in the xmm registers because that is the ABI that was agreed on long ago by a group of experienced experts involved in the design of the processor (the 64-bit AMD processors, since they pre-dated Intel's 64-bit x86 chips), compiler design, and operating system design (since it is the ABI for 64-bit x86 Linux we are discussing). It is quite possible that Ian was part of that group - he is an experienced expert - but it was not his decision. And it is /not/ going to change. The ABI is fixed - you have to live with it. I'm sure there are many aspects of the 32-bit x86 ABI that people would like to change, since it was fixed in stone before features like xmm registers were part of the x86 cpus. But that doesn't happen - you have to keep the ABI consistent. For purely internal code - static functions without external linkage - the compiler can use whatever calling conventions it wants. If you think that such calls could be done better, then that can be discussed or filed as missed optimisation bug reports. In the particular case of passing floating point arguments, of course, the extra step needed to move data from an xmm register onto the stack for the fsin code is totally negligible. The great majority of floating point operations /are/ handled by SSE instructions, since operations such as load, store, register move, and basic arithmetic outweigh the use of transcendental functions by many orders of magnitude. You do not change the ABI used by an entire operating system to shave a few clock cycles off an unusual piece of test code to calculate pi. mvh., David
Re: calculation of pi
I think this thread belongs on the gcc-help list, not here.
Re: calculation of pi
On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: On Sat, Nov 3, 2012 at 12:55 AM, Mischa Baars mjbaars1...@gmail.com wrote: On 11/02/2012 07:11 PM, Ian Lance Taylor wrote: On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars mjbaars1...@gmail.com wrote: I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. I have not looked at your code. However, I can tell you that on 32-bit x86 floating point function arguments are normally passed on the stack and on 64-bit x86 floating point arguments are normally passed in the xmm registers. There are various ways that you can change this default behaviour, but if you are seeing an unexpected change then I would guess that you changed from 32-bit compilation to 64-bit compilation. Ian By the way, it seems this only holds for single and double real numbers. These are indeed passed in xmm registers, the long double however is still passed over the stack. Yes. Do we have any compiler options that change this behaviour back to the original? The default behaviour in 64-bit mode is not even the same for all real number types. There is no original. The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Ian Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. Mischa.
Re: calculation of pi
On 04/11/12 10:34, Mischa Baars wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: On Sat, Nov 3, 2012 at 12:55 AM, Mischa Baars mjbaars1...@gmail.com wrote: On 11/02/2012 07:11 PM, Ian Lance Taylor wrote: On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars mjbaars1...@gmail.com wrote: I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. I have not looked at your code. However, I can tell you that on 32-bit x86 floating point function arguments are normally passed on the stack and on 64-bit x86 floating point arguments are normally passed in the xmm registers. There are various ways that you can change this default behaviour, but if you are seeing an unexpected change then I would guess that you changed from 32-bit compilation to 64-bit compilation. Ian By the way, it seems this only holds for single and double real numbers. These are indeed passed in xmm registers, the long double however is still passed over the stack. Yes. Do we have any compiler options that change this behaviour back to the original? The default behaviour in 64-bit mode is not even the same for all real number types. There is no original. The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Ian Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. Mischa. I am completely failing to see your problem here. gcc is a C (and C++, Fortran, etc.) compiler. When you write C code, there are only two reasons for caring about ABI and parameter passing - one is that it should be as efficient as possible, and the other is that for external linkage code, it should conform to the platform's standard ABI so that you can link to libraries, or assembly code written to match the ABI. The 64-bit ABI uses the xmm registers for efficiency. This is a /good/ thing. Write your code in C, and it will work correctly and efficiently whether it is compiled as 32-bit or 64-bit code. If you want to use a little bit of assembly in your C code (I don't know why you want to do so here, but I presume you've got good reasons - such as for learning), then I strongly recommend you learn about gcc's inline assembly syntax. It will save you from worrying about what data is in which place, since it will handle such moves for you. And it will give you more efficient code, and is easier to work with for small assembly functions. David
Re: calculation of pi
On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars mjbaars1...@gmail.com wrote: On 11/04/2012 02:45 AM, Ian Lance Taylor wrote: There is no original. The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Sounds more logical to me, that a least all types of numbers are treated in the same manner. I suppose the ABI should be modified then if you ask me. An ABI is by definition processor specific. The placement of argument values is chosen based on runtime efficiency, not on any other sort of logic. On x86_64, 32-bit and 64-bit float values can be passed directly in registers, as the x86_64 has efficient 32-bit and 64-bit floating point registers. The x86_64 does not have floating point registers that can efficiently store floating point values with more than 64 bits, so those values are not passed in floating point registers. To make any other choice would cost runtime efficiency, which is the only logic that matters. Ian
Re: calculation of pi
On 11/02/2012 07:11 PM, Ian Lance Taylor wrote: On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars mjbaars1...@gmail.com wrote: I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. I have not looked at your code. However, I can tell you that on 32-bit x86 floating point function arguments are normally passed on the stack and on 64-bit x86 floating point arguments are normally passed in the xmm registers. There are various ways that you can change this default behaviour, but if you are seeing an unexpected change then I would guess that you changed from 32-bit compilation to 64-bit compilation. Ian Probably I have. But when I pass the -m32 parameter I get an unexpected error: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory which also prevents me from compiling the compiler under Fedora 17. This means that I am both not able to compile programs in 32-bit mode and help you with the compiler. Is there a solution and what are the exact alternatives you refer to? Mischa
Re: calculation of pi
On 11/02/2012 07:11 PM, Ian Lance Taylor wrote: On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars mjbaars1...@gmail.com wrote: I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. I have not looked at your code. However, I can tell you that on 32-bit x86 floating point function arguments are normally passed on the stack and on 64-bit x86 floating point arguments are normally passed in the xmm registers. There are various ways that you can change this default behaviour, but if you are seeing an unexpected change then I would guess that you changed from 32-bit compilation to 64-bit compilation. Ian By the way, it seems this only holds for single and double real numbers. These are indeed passed in xmm registers, the long double however is still passed over the stack. Do we have any compiler options that change this behaviour back to the original? The default behaviour in 64-bit mode is not even the same for all real number types. Mischa.
Re: calculation of pi
On 11/3/2012 3:32 AM, Mischa Baars wrote: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory which also prevents me from compiling the compiler under Fedora 17. This means that I am both not able to compile programs in 32-bit mode and help you with the compiler. Normally, this means you didn't install the optional (32-bit) glibc-devel i386. -- Tim Prince
Re: calculation of pi
On 11/03/2012 12:41 PM, Tim Prince wrote: On 11/3/2012 3:32 AM, Mischa Baars wrote: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory which also prevents me from compiling the compiler under Fedora 17. This means that I am both not able to compile programs in 32-bit mode and help you with the compiler. Normally, this means you didn't install the optional (32-bit) glibc-devel i386. Yes, you are right! You need to install both 'glibc-devel.i686' and 'libgcc.i686', however you need to do this manually with 'yum' because they do not appear on the list of installable packages with the 'add/remove software' applet. Mischa.
Re: calculation of pi
On Sat, Nov 3, 2012 at 12:55 AM, Mischa Baars mjbaars1...@gmail.com wrote: On 11/02/2012 07:11 PM, Ian Lance Taylor wrote: On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars mjbaars1...@gmail.com wrote: I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. I have not looked at your code. However, I can tell you that on 32-bit x86 floating point function arguments are normally passed on the stack and on 64-bit x86 floating point arguments are normally passed in the xmm registers. There are various ways that you can change this default behaviour, but if you are seeing an unexpected change then I would guess that you changed from 32-bit compilation to 64-bit compilation. Ian By the way, it seems this only holds for single and double real numbers. These are indeed passed in xmm registers, the long double however is still passed over the stack. Yes. Do we have any compiler options that change this behaviour back to the original? The default behaviour in 64-bit mode is not even the same for all real number types. There is no original. The 32-bit and 64-bit ABIs are different. The 64-bit ABI has always passed arguments in registers. There is no option to force the 64-bit compiler to pass arguments on the stack. Ian
Re: calculation of pi
On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars mjbaars1...@gmail.com wrote: I have been writing this piece of example code, but it seems that someone has been modifying the compiler in the meantime such that arguments are now passed in xmm registers instead of over the stack. Also the npx top of stack pointer isn't handled alike for all three different types of real numbers on function return any more. I have not looked at your code. However, I can tell you that on 32-bit x86 floating point function arguments are normally passed on the stack and on 64-bit x86 floating point arguments are normally passed in the xmm registers. There are various ways that you can change this default behaviour, but if you are seeing an unexpected change then I would guess that you changed from 32-bit compilation to 64-bit compilation. Ian
