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,c95a73ec6ed5f174
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Floating point problem
Date: 1997/03/28
Message-ID: <dewar.859583580@merv>#1/1
X-Deja-AN: 229120608
References: <199703271518_MC2-1360-15BE@compuserve.com> <dewar.859526944@merv>
 <1997Mar28.095005.1@eisner>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-03-28T00:00:00+00:00
List-Id: <comp.lang.ada>


<<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.>>

Who knows what particular hardware a particular program might require.
So far, we have had no one who has had an interest in this kind of
ayutomatic detection. Note that doing it automatically is far from
trivial, since you have to arrange to reliably trap the fpt operations
and field the traps -- it's just something that is not on our current
list of requirements. We have relatively few serious customers using
low end machines, and none interested in their software working on
a 486sx or rather, as Larry discusses, NOT working "reliably".

If you do want to add this check to your software, or to check for
any other hardware, it is easy enough to do, the cookbook recipe for
checking for the presence of an fpt processor is in the Intel docs.

Going back to our requirements. Right now, virtually all our x86
customers are developing in environments which would not feasibly
run on non-fpt machines in the first place. The first exception will
be for embedded x86 targets, and there we definitely will address
the problem (since some of these targets have no fpt).

I never heard of any serious developer using Unix, OS/2 or NT on
a 486SX class machine, given that reasonable machines can be obtained
for well under $1000 these days, it seems unlikely, as I mentioned
before, that those working on SX class machines are likely to be
a source of a critical customer base!

Actually I would guess that Larry is not in fact concerned about trying
to use GNAt in that environment for his own use, but is rather operating
in "gadfly" mode, which is fine, people are always free to suggest all
sorts of things for GNAT, and occasionally the suggestions are good ones
which can influence what we do, even if no immediate $$$ are involved, so
it's fine to make suggestions.

But I am afraid that working to make GNAT more reliable on low end obsolte
machines running low end x86 operating systems is NOT likely to be on our
work schedule in the forseeable future!