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,efbcb7a47025db16
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Effort to Port TSG to Ada-95 and How Fast it Ran in Gnat
Date: 1997/02/21
Message-ID: <dewar.856573561@merv>#1/1
X-Deja-AN: 220580870
References: <5efjta$jlm@top.mitre.org> <dewar.856407400@merv>
 <E5xLBK.n13@thomsoft.com>
Organization: New York University
Keywords: Ada-95, gnat, port, conversion, optimization, program_error
Newsgroups: comp.lang.ada
Date: 1997-02-21T00:00:00+00:00
List-Id: <comp.lang.ada>


Keith says

<<This is possible according to the Ada language definition, but it
seems unlikely to happen in real life.  Typically, Ada floating-point
comparisons are implemented simply by generating the appropriate hardware
compare instructions.  These instructions don't know anything about
Ada's concept of model numbers, they just operate on the bits.>>

wishful thinking I am afraid. In practice funny things can happen. Consider
the following:

    if a + b > 3.45 then ...

    if a + b = 3.45 then ...

it can easily happen that both of these are true, due to extra temporary
precision in intermediate results. FOr example, consider you are on an
x86 where all registers are 80 bits, and the initial comparison computes
a+b into an 80 bit register and compares it. But the second comaprison
uses a saved value of a+b, which was unfortunately stored in memory in
a 64-bit temporary.

This sort of thing happens in real life all the time on such machines!