Re: Floating point problem

[kilgallen@eisner.decus.org (Larry Kilgallen)]

In article <dewar.859526944@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry Kilgallen <kilgallen@EISNER.DECUS.ORG> wrote
> on the subject of a floating-point coprocessor being needed for use
> of the GNAT compiler:
> 
>>That is too bad.  I had hoped GNAT might be useful for deployment.
>>Just to make sure we are on the same wavelength, my concern is
>>entirely with what happens at runtime with generated programs.
>>For running the compiler I can buy (actually already have) some
>>appropriate machines.
> 
> Actually I think there is no big problem in using GNAT in an environment
> in which floating-point needs to be simulated. It's not a big task to
> provide for emulating floating-point. We didn't do it yet, because
> we have not encountered a customer interested in such a product
> (interested means more than just saying on CLA that you are interested!)

Personally I don't have much need for floating point on machines
without hardware floating point.  My only concern is that generated
code fail in a highly predictable fashion if the environment is not
correct in such a major fashion as this.  If my program makes
no explicit calls to floating point and the runtime library is
going to fail in the absence of floating point, I would think
that automatic detection would be in order.

Considering that the Ada software environment is one where
the type of the argument must match the the formal argument
more closely than in any other language, I would expect the
match between the hardware environment and the required
hardware environment would also be carefully checked on
a non-optional basis.

If the Ada approach is that runtime machine environment
checking is to be entirely manual, I guess the community
is still too centered around the military project model
rather than the model of providing "shrink-wrapped" software.

Obviously this is only a problem where the operating system
does not defend the program against lack of hardware support.

Larry Kilgallen