This is the mail archive of the gcc-patches@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: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips


On Wed, 2009-03-04 at 20:24 +0000, Richard Sandiford wrote:
> (I'm somewhat surprised no "as-if" rule applies here.  Is software FP,
> or running programs under a system emulator or application translator,
> really not allowed?)

It's obviously allowed as long as the software routines are
implemented to the correct precision, which seems not the
case for 128 bits mips one if one believe the ACATS testsuite results
for the Numerics annex (cxgxxx), eg:

,.,. CXG2010 ACATS 2.5 09-03-01 18:15:34
---- CXG2010 Check the accuracy of the exp function.
   * CXG2010 test 1 -- exp(1) actual:  2.71828182845904509E+00 expected:
                2.71828182845904524E+00 difference:
                -1.44632569809566291E-16 max err:
                1.17886682553726646E-18.

If we check:

$ bc -l
scale = 18
e (1)
2.718281828459045235
Ada expects:
2.71828182845904524
which seems coherent with bc
128 bit mips soft fp seems to return:
2.71828182845904509
which seems wrong in the two last digits. Now I don't know
who provides the 128 bits soft FP code, and there
may be something wrong before we reach such code.

Then an Ada implementation has no obligation to provide 128 bits
Long_Long_Float, the RM only says:

                         Implementation Requirements

14    {Float} In an implementation that supports floating point types with 6
or more digits of precision, the requested decimal precision for Float shall
be at least 6.

15    {Long_Float} If Long_Float is predefined for an implementation, then its
requested decimal precision shall be at least 11.
...
                         Implementation Permissions

16    {Short_Float} {Long_Float} An implementation is allowed to provide
additional predefined floating point types[, declared in the visible part of
Standard], whose (unconstrained) first subtypes have names of the form
Short_Float, Long_Float, Short_Short_Float, Long_Long_Float, etc. Different
predefined floating point types are allowed to have the same base decimal
precision. However, the precision of Float should be no greater than that of
Long_Float. Similarly, the precision of Short_Float (if provided) should be no
greater than Float. Corresponding recommendations apply to any other
predefined floating point types. There need not be a named floating point type
corresponding to each distinct base decimal precision supported by an
implementation.

    16.a  Implementation defined: The predefined floating point types declared
          in Standard.


                            Implementation Advice

17    {Long_Float} An implementation should support Long_Float in addition to
Float if the target machine supports 11 or more digits of precision. No other
named floating point subtypes are recommended for package Standard. Instead,
appropriate named floating point subtypes should be provided in the library
package Interfaces (see B.2).

Now it's not unreasonable for an implementor to say that Long_Long_Float
is defined on all platforms and maps to the widest float implemented
in hardware.

Laurent


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