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
