comp.lang.ada
 help / color / mirror / Atom feed
From: Corey Ashford <yeroca@rocketmail.com>
Subject: Re: Code portability question
Date: 1999/01/25
Date: 1999-01-25T00:00:00+00:00	[thread overview]
Message-ID: <36ABE8BF.FFBD087F@rocketmail.com> (raw)
In-Reply-To: 78gem9$imp$1@nnrp1.dejanews.com

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




  reply	other threads:[~1999-01-25  0:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-22  0:00 Code portability question Mike Werner
1999-01-23  0:00 ` Corey Ashford
1999-01-23  0:00   ` bill_1
1999-01-24  0:00   ` Mike Werner
1999-01-24  0:00     ` Corey Ashford
1999-01-25  0:00       ` robert_dewar
1999-01-25  0:00         ` Corey Ashford [this message]
1999-01-25  0:00           ` dewar
1999-01-23  0:00 ` bill_1
1999-01-24  0:00   ` Mike Werner
1999-01-23  0:00 ` Tucker Taft
1999-01-24  0:00   ` Mike Werner
1999-01-31  0:00     ` Nick Roberts
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox