From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,544e7f5698c48b7c X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: precise floats Date: 1998/08/08 Message-ID: #1/1 X-Deja-AN: 379147136 References: <6q7vtb$jk$1@heliodor.xara.net> <6q8afs$5aq$1@usenet.rational.com> <6q8b4a$5cu$1@usenet.rational.com> <6qco5r$v8n$1@nnrp1.dejanews.com> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 902580737 15579 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1998-08-08T00:00:00+00:00 List-Id: Paul said <> That's reasonable, and the names here are expected (since they correspond to the the implementation note B.2(10.a) in the AARM). Note that purists might object to the appearence of IEEE rather than the proper ISO name here, but in practice everyone talks about IEEE floating-point (it has been one of the real name recognition successes for IEEE :-) However, the above definitions are most certainly inadequate on the x86. This machine fully supports the 80-bit floating-point format corresponding the optional IEEE extended type. Indeed all arithmetic in the fpt chip is in fact performed in this mode. The ia32 (x86) is essentially the only widely used chip that has this extended precision, and it is an extremely important capability, since it allows algorithms to be used that otherwise would not be usable (e.g. you cannot compute x**y using log/exp without introducing horrible errors, but if you use extended precision to compute x**y using log/exp, you can get accurate 64-bit answers -- see chapter 5 of my book Microprocessors: A Programmer's View, McGraw Hill 1990 for details). This type then is most definitely covered by the requirement in B.2(10), and for an x86 implementation, must be defined in Interfaces. The relevant definitions from the GNAT version of Interfaces are type IEEE_Float_32 is new Short_Float; pragma Float_Representation (IEEE_Float, IEEE_Float_32); type IEEE_Float_64 is new Long_Float; pragma Float_Representation (IEEE_Float, IEEE_Float_64); type IEEE_Extended_Float is new Long_Long_Float; pragma Float_Representation (IEEE_Float, IEEE_Extended_Float); and Long_Long_Float is indeed the 80-bit format on the x86. Note that it is usually the case that Long_Long_Float is the same as long double in C. However this is not always the case. On the SPARC, where the 128-bit format is NOT supported by the hardware, we consider that the proper approach is not to provide this 128-bit format as a first class citizen in the world of base types that are intended to reflect the types implemented in the hardware. Note: some people sometimes get confused into thinking that somehow the 80-bit format is "reserved" and should not be used. This derives from the intention in the IEEE-754 standard that the extended format be used for the purposes of getting accurate 64-bit results (e.g. in the log/exp case above). However, this is not an excuse for disobeying B.2(10), because: (a) this is only an intention reflected in the design of 754, which is in no way reflected in the hardware, and is essentially just programming advice which a programmer is free to ignore. If your application will successfully run using 64-bit mantissa precision and not 53-bit mantissa precision, then you will be happy to find out that the x86 (and incidentally the forthcoming ia64 [merced]) satisfy your needs, and you will not be happy to find that your Ada compiler arbitrarily eliminates this possibility. (b) code that reflects the intention of IEEE-754 and uses the extended format for intermediate results in the intended manner may perfectly well be written in Ada! Note that I have no idea what other Ada compilers do here. All I know is that the standard mandates the inclusion of the 80-bit format in the Interfaces definition for a conforming Ada 95 compiler for the x86. We have already seen that people can get confused when they tell us what is and what is not in some particular compiler. So you should check for yourself to make sure that your compiler meets this requirement. It is indeed a requirement that should be checked by the validation suite, but in practice this kind of checking is hard. You can parametrize the validation suite by specifying the maximum fpt precision, but it is difficult to check that this parametrization is done correctly when it is machine dependent. Robert Dewar Ada Core Technologies