[discuss] RFC: Support IEEE 754R draft in the x86-64 psABI

Daniel Jacobowitz drow at false.org
Thu May 11 23:27:40 CEST 2006


On Thu, May 11, 2006 at 11:13:09AM -0700, Cornea, Marius wrote:
> While trying to keep my reply short, I have to say this again: we ran a
> comparison between our implementation and decNumber because decNumber is
> the only other 754R decimal implementation

This is a good reason...

> and because it is going to
> be used by GCC for decimal floating-point arithmetic

But this is not...

> (but the results
> show that GCC could possibly use a faster implementation of the 754R
> decimal floating-point arithmetic :-)).

And this is not necessarily what it shows.

We've done lots of work in the past for floating point formats in GCC,
which has a close parallel here.  The verdict has always been that
while faster is better than slower, performance of floating point
arithmetic in GCC is basically irrelevant.  Accuracy, precision,
and flexibility, on the other hand, are vital.  The libraries used
by GCC to simulate target arithmetic must be able to do so in a variety
of formats and matching the requirements of the relevant language
standards and underlying hardware implementations, especially when
those hardware implementations are not available at compile time.

>From what I've heard about decNumber GCC is an example of an ideal
usage for it: a single library which can, reasonably efficiently and
extremely accurately, be used for a wide variety of formats.  Similarly
for GDB.

Now, what you may be talking about is something very different from
what your words say: the fact that not only does GCC use decNumber at
compile time, but it also generates calls to it at runtime.  However,
they are all very carefully abstracted away and the interface has no
reliance on decNumber.  If someone contributed a faster implementation
for a particular format, to be used at runtime on a particular target,
GCC would surely go ahead and use it.  Similarly, on upcoming hardware
with native support for decimal float operations, GCC will doubtlessly
be extended to use it.

-- 
Daniel Jacobowitz
CodeSourcery



More information about the discuss mailing list