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,FREEMAIL_FROM,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,dec0a6ed5b5044de
X-Google-Attributes: gid103376,public
From: Corey Ashford <yeroca@rocketmail.com>
Subject: Re: Code portability question
Date: 1999/01/25
Message-ID: <36ABE8BF.FFBD087F@rocketmail.com>#1/1
X-Deja-AN: 436541307
Content-Transfer-Encoding: 7bit
References: <36A94B78.963F3215@wvu.edu> <36A9849C.A9FE01E4@rocketmail.com>
 <36AABFAA.2D844356@wvu.edu> <36AB878E.F51CA837@rocketmail.com>
 <78gem9$imp$1@nnrp1.dejanews.com>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: Rational Software
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-01-25T00:00:00+00:00
List-Id: <comp.lang.ada>

robert_dewar@my-dejanews.com wrote:
> 
> In article <36AB878E.F51CA837@rocketmail.com>,
>   Corey Ashford <yeroca@rocketmail.com> wrote:
[snipped]
> > The AMD processor is supposed to be an exact clean-room
> > implementation of the
> > IA32 architecture (plus their 3D enhancements).
> > I think the chances of the problem being due to a
> > difference in the floating point register implementation
> > are about, as you surmised, zero.
> 
> Wait a moment! This is going in a bizarre direction. It is'
> OF COURSE the case that the K6 (and any other ia32
> implementation) has radically different floating-point
> behavior, namely it implements 80-bit floating-point
> formats which are typically used for intermediate values.
> It would be quite possible to create an algorithm that was
> stable on the ia32 and unstable on a 64-bit Unix
> implementation, and this is possible even if all the
> declared variables are float and long_float (remember these
> types are unconstrained in Ada 95, so they can use the
> 80-bit format at the compiler's discretion).

Somehow I was thinking that the machine they were going from
was a K6 and the machine they ended up on was an Intel Pentium.

Assuming the machine they ended up on was SPARC, the precision of
float, long_float etc. may well be different (they aren't different
on the Rational Ada compiler, but probably are on GNAT).

If the programmer had specified the precision of the float types
he was using, then there shouldn't have been any problem.  Right?

This is one reason why I stated earlier that code has to be written
with portability in mind.

> 
> I think this is unlikely, but it is a WHOLE lot more likely
> than worrying about the AMD 3-D instructions!

Yup.  Agreed.

Thanks for your comments.

- Corey