This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Are Decimal operations are fully implemented/tested ?


On 2012-09-13 16:46:04 +0000, Joseph S. Myers wrote:
> On Thu, 13 Sep 2012, Vincent Lefevre wrote:
> > But if you want an example, I don't think that the formatOf
> > arithmetic operations (IEEE 754-2008 §5.4.1 -- that's a "shall")
> > are implemented by GCC, either for binary or for decimal, say
> > add two _Decimal128 numbers and round to _Decimal64 directly
> > (with a single rounding).
> 
> For binary floating point, the draft C bindings (I'm looking at WG14 
> N1605, which is just a draft of the first part of what's supposed to end 
> up as a five-part document) defines such operations as library operations 
> (e.g. float fadd(double x, double y);) rather than compiler ones (although 
> of course the compiler might have corresponding built-in functions).  

Note however that efficiency is important. If one had to choose to
spend time on compiling/implementing these operations, the focus
should be on the compiler first (actually, that's particularly
true for binary on IA-64, where these operations are part of the
instruction set and implemented in hardware on the Itanium).

Also if the (software) implementation of _Decimal64 operations and
_Decimal128 operations is done by GCC, it would be better to have
the implementation of the corresponding formatOf operations done
by GCC too (keep similar code at the same place).

> (Implementing fadd itself probably isn't hard; given exception and 
> rounding mode support you should be able to do it with round-to-odd as 
> described by Boldo and Melquiond

round-to-odd would be a good solution if it were provided directly
in hardware. Otherwise a "direct" implementation would probably be
more efficient (in particular when the implementation of the usual
operation is done in software, like for decimal arithmetic).

Note: What makes round-to-odd work is that one gets a good enough
approximation to the exact result, and the sign of the error w.r.t.
a format with less precision is "encoded" in the result itself;
and all this information is kept in a single floating-point number.
But if you need to implement a formatOf operation and round-to-odd
isn't directly available, it may be better to get the approximation
and the error (or just its sign) in some more usual way, and work
with them without "packing" them in a single floating-point number.

> - and some processors (ia64?) may have direct support for it.

In binary only (because it doesn't have decimal support at all).

> But there are lots of new functions, that's just one.)

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]