Re: Five Years After

[Robert Eachus <rieachus@comcast.net>]

On Wednesday, January 24, 2018 at 2:06:52 PM UTC-5, Simon Clubley wrote:

> Oh, and about item (4). Apart from needing to call adainit/adafinal,
> there's this little gem taken from:
> 
> https://gcc.gnu.org/onlinedocs/gnat_ugn/Binding-with-Non-Ada-Main-Programs.html
> 
> |Currently the GNAT run time requires a FPU using 80 bits mode precision. Under
> |targets where this is not the default it is required to call
> |GNAT.Float_Control.Reset before using floating point numbers (this include
> |float computation, float input and output) in the Ada code. A side effect is
> |that this could be the wrong mode for the foreign code where floating point
> |computation could be broken after this call. 

This may look horrible/  It is correct, but not very horrible.  There are four use cases here:

1) You are on a PC with an x86, AMD64 (EM64_T), an IBM mainframe or several other chips?  On the PC there is 80-bit support (old x87 floating-point) but you may prefer to use SIMD 64-bit floating point.  On IBM Z-series, they have a funky 128-bit type which may fit your needs.  Anyway you are covered (just use Float for 32-bits or Long_Float for 64-bits.  If the compiler wants to use 80-bit (IEEE Extended) for multiplication or division with two fixed point operands, or fixed-point value output?  Expect the (GNAT) compiler to handle those cases correctly.

2) You are on a chip which only supports up to 64-bit float types, and need more.  Years ago I wrote a package to do 64-bit float and integer arithmetic on machines which only supported up to 32 bit types.  Hmmm. A 64-bit to 128-bit float package should be possible, one sign bit, a 31-bit exponent and a 97 bit mantissa including a hidden bit shouldn't be too hard.  But this should be a very small class.  When high precision is needed even supercomputers use polynomials in nth roots of one.*

3) You use 64-bit float and really care about the IEEE features like signed zeroes, soft underflow, etc.*  If the settings you care about are supported, this is warning you that the code calling the Ada program may set the values in a way you don't like.  Worse, you need settings which are not supported by the chip.  Tough!  In theory, compilers should provide software to emulate features that are not provided in hardware.  For some settings, this is easy. for some like rounding modes, very, very tough.  You just have to ask yourself if you can live with the hardware.  If you can't why are you living with the hardware?

4) If you don't care about these issues, or more likely don't know enough about them to care?  Put in the GMAT.Float_Control_Reset call if the code will be running on a machine that needs it, and be aware that you could be living in a state of sin.  If both the calling code and the Ada code use floating point types, and you expect to pass floating point parameters or data back and forth?  You are not only living in a state of sin, but may be getting errors all over the place.  (Worse, if you don't run and check test cases with known results, the code may run and produce bad answers!)  In any case you will need to learn enough about (IEEE) floating point types to make sure that both halves of the program are using the same formats.

What punishment goes with case 4?  You may be forced to read Annex G.  Worst case, read Annex G, IEEE 754-3008 and the GNAT documentation.  Reading this might save a lot of pain: http://steve.hollasch.net/cgindex/coding/ieeefloat.html

As an example of the trouble you might get into, C specifies that certain float functions actually take IEEE double values as parameters.  If passed in registers, no real problems, but passing such values on the stack may be lethal.  I can tell you that such dragons exist but I don't even know the names of all the languages where they can be hiding.  (If all else fails, pass the exponent and mantissa separately as integers.  Used to have to do that to interface between DEC VAXes and other minicomputers.)

* Decades ago, there was a special issue of Ada Letters which included the full NUMWG report, including source, I think for test code which disassembled floating-point numbers into exponent and mantissa.  Is that source on-line anywhere?  I think it supports up to 128-bit float types, but the code is designed for accuracy and readability, not speed.