Does Ada 95 conform to the IEEE 754 floating point standard?

[Samir N. Muhammad]

Hello Everyone

Does anyone know whether the Ada 95 standard say anything about the conformance
of Ada 95 to the IEEE 754 standard (i.e. floating point standard). I checked
some sections of the standard and could not find such information. Any pointers
(especially to the standard) are highly appreciated.

Thanks in advance
Samir Muhammad

[Robert Dewar]

Samir asks

<<Does anyone know whether the Ada 95 standard say anything about the conformance
of Ada 95 to the IEEE 754 standard (i.e. floating point standard). I checked
some sections of the standard and could not find such information. Any pointers
(especially to the standard) are highly appreciated.
>>

The IEEE 754 standard is a combined hardware/software standard that requires
certain facilities to be available at the programming language level.

Most certainly the Ada 95 RM does not require IEEE conformance, since it is
designed to run on machines which do not implement reasonable hardware for
this purpose. The intention is that Ada 95 compilers map to the underlying
floating-point hardware, whether or not it is IEEE compliant or consistent.

Even on an IEEE machine, Ada 95 will implement only a subset of the
754 (or 854 remember the update) standard.

However, a big difference in Ada 95, compared to Ada 83, is that
Ada 95 is "IEEE-ready", in that it is not inconsistent with the
standard, whereas with Ada 83 there were some definite glitches
in this respect.

What you need in Ada 95 is a package that provides required features,
plus some additional support from the compiler. My PhD thesis student
Sam Figueroa is working on a thesis that examines the issues of IEEE
compliance in high level languages, and one of the work products is
a complete binding for IEEE that we intend to fully implement in GNAT.

Robert Dewar

[Joe Gwinn]

Ada95 allows one to use the arithmetic built into the processor one's
program runs on. If that hardware complies to IEEE 754, so much the
better, but Ada has nothing to do with it, and nor should it.

IEEE 754 is a hardware representation, handled by the computer. To access
these 32-bit single-real numbers, one must declare variables as type
"float" in ANSI C or type "FLOAT" in Ada [LRM section 3.5.7]. To access
64-bit double-real numbers, one must declare variables as type "double" in
C or type "LONG_FLOAT" in Ada [Ada LRM section 3.5.7]. In Fortran-77
[ANSI X3.9-1978, Section 4], these types are called "real" and "double
precision" respectively.

Note that it isn't enough to say only that a variable is a single (32-bit)
float or a double (64-bit) float. There must be fifty different
floating-point formats in existence, especially in legacy systems. IEEE
754 is steadily displacing all other formats, but it will be some time
before all other formats have totally disappeared.

Joe Gwinn

In article <6b8fdn$qr...@beaker.nit.gwu.edu>, sam...@seas.gwu.edu (Samir
N. Muhammad) wrote:

> Hello Everyone

>
> Does anyone know whether the Ada 95 standard say anything about the
conformance
> of Ada 95 to the IEEE 754 standard (i.e. floating point standard). I checked
> some sections of the standard and could not find such information. Any
pointers
> (especially to the standard) are highly appreciated.
>
>

[Matthew Heaney]

In article <gwinn-04029...@dh5055139.res.ray.com>,
gw...@res.ray.com (Joe Gwinn) wrote:

>IEEE 754 is a hardware representation, handled by the computer. To access
>these 32-bit single-real numbers, one must declare variables as type
>"float" in ANSI C or type "FLOAT" in Ada [LRM section 3.5.7]. To access
>64-bit double-real numbers, one must declare variables as type "double" in
>C or type "LONG_FLOAT" in Ada [Ada LRM section 3.5.7].

It might be better to use the types Interfaces.IEEE_Float_32 and
Interfaces.IEEE_Float_64, because you have no guarantee that types Float
and Long_Float are any different. If you want the IEEE format, then state
that explicitly, by using the types in package Interfaces. See AARM B.2
(10.a).

[Robert Dewar]

Joe said

<<In article <gwinn-04029...@dh5055139.res.ray.com>,
gw...@res.ray.com (Joe Gwinn) wrote:

>IEEE 754 is a hardware representation, handled by the computer. To access
>these 32-bit single-real numbers, one must declare variables as type
>"float" in ANSI C or type "FLOAT" in Ada [LRM section 3.5.7]. To access
>64-bit double-real numbers, one must declare variables as type "double" in
>C or type "LONG_FLOAT" in Ada [Ada LRM section 3.5.7].
>>

Earlier, Joe and I had a long discussion about the importance of knowing
the language as opposed to the implementation, among other things. Joe
dismissed this as requiring "ada experts" ...

But the above is a good example of sloppiness that comes from not making
this distinction, and this kind of error can cause huge problems in
porting code later on.

There is absolutely NO indication, let alone a guarantee, that on an
IEEE machine, float will map to IEEE short and LONG_Float to IEEE long
(the same is true of ANSI C).

Yes, it is a likely choice, but there have been Ada compilers, where
Float was 64-bits and you had to use Short_Float to get 32 bits.

In Ada 83, the best shot would be something like

type IEEE_Short is digits 6;
type IEEE_Long is digits 15;

there is no still no requirement in Ada 83 that you will get what you
want. You could however confirm that the right choices have been made
using:

for IEEE_Short'Size use 32;
for IEEE_Long'Size use 64;

but that still would not be adequate on an Alpha, where there is nothing
to stop the compiler from choosing Vax Float formats in both cases (indeed
DEC Ada 83 does choose Vax Float by default).

In Ada 95, the problem is entirely solved by using the appropriate types
in Interfaces.

In any case, Joe's advice is badly flawed. To use the predefined types
Float and Long_Float is really asking for trouble. Even in Ada 83, where
there is no 100% guaranteed way of ensuring you get the IEEE types, the
proper approach is to define types in the above manner and use them.

This way, you only have to make changes at one small point in your program
when you port (e.g. in DEC Ada 83, use the pragma Float_Representation).
Note that this advice also applies to C. In C, there is even less control
to help ensure getting the right types, but by using typedefs, you can
isolate the degree of change.

This kind of abstraction is absolutely essential in programming if you
want to write portable code.