calculation of pi

calculation of pi

[Mischa Baars]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

Hi,

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.

Assistance would be appreciated.

Regards,
Mischa.

[-- Attachment #2: 2011071802 - series expansion (pi).tar.bz2 --]
[-- Type: application/x-bzip, Size: 3671 bytes --]

Re: calculation of pi

[Ian Lance Taylor]

On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars <mjbaars1977@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

Re: calculation of pi

[Mischa Baars]

On 11/02/2012 07:11 PM, Ian Lance Taylor wrote:
> On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars <mjbaars1977@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

[Mischa Baars]

On 11/02/2012 07:11 PM, Ian Lance Taylor wrote:
> On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars <mjbaars1977@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

[Tim Prince]

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

[Mischa Baars]

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

[Mischa Baars]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On 11/03/2012 02:46 PM, Mischa Baars wrote:
> 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.

Let me resend the example, now it will work on 64-bit machines in 32-bit 
compiler mode. However, problems do occur when trying to convert the 
code to 64-bit code.

Mischa.

[-- Attachment #2: 2011071802 - series expansion (pi).tar.bz2 --]
[-- Type: application/x-bzip, Size: 65631 bytes --]

Re: calculation of pi

[Ian Lance Taylor]

On Sat, Nov 3, 2012 at 12:55 AM, Mischa Baars <mjbaars1977@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 <mjbaars1977@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

[Mischa Baars]

On 11/04/2012 02:45 AM, Ian Lance Taylor wrote:
> On Sat, Nov 3, 2012 at 12:55 AM, Mischa Baars <mjbaars1977@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 <mjbaars1977@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

[David Brown]

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 <mjbaars1977@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 <mjbaars1977@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

[Ian Lance Taylor]

On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars <mjbaars1977@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

[Mischa Baars]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On 11/05/2012 05:55 AM, Ian Lance Taylor wrote:
> On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars <mjbaars1977@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.

[-- Attachment #2: 2012110500 - arguments.tar.bz2 --]
[-- Type: application/x-bzip, Size: 6714 bytes --]

Re: calculation of pi

[David Brown]

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 <mjbaars1977@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

[Jonathan Wakely]

I think this thread belongs on the gcc-help list, not here.

Re: calculation of pi

[Mischa Baars]

[-- Attachment #1: Type: text/plain, Size: 3913 bytes --]

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 <mjbaars1977@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.

[-- Attachment #2: 2012110501 - division by zero.tar.bz2 --]
[-- Type: application/x-bzip, Size: 3211 bytes --]