Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!fatcity!khb
From: khb@fatcity.Sun.COM (Keith Bierman Sun Tactical Engineering)
Newsgroups: comp.arch
Subject: Re: Query about miserable M68882 performance [really 80-bit notes]
Message-ID: <97749@sun.Eng.Sun.COM>
Date: 6 Apr 89 09:13:48 GMT
References: <2583@tank.uchicago.edu> <7829@pyr.gatech.EDU> <16543@winchester.mips.COM>
Sender: news@sun.Eng.Sun.COM
Reply-To: khb@sun.UUCP (Keith Bierman Sun Tactical Engineering)
Organization: Sun Microsystems, Mountain View
Lines: 42

In article <16543@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>In article <7829@pyr.gatech.EDU> mccalpin@loligo.cc.fsu.edu (John McCalpin) writes:
>...
>>On the bright side, both the Intel and Motorola chips make it easy
>>to implement a robust IEEE-compliant floating-point system, since just
>>about everything is done by the hardware.  If the compiler is smart about
>>keeping intermediate results on the co-processor's internal stack, then
>>the extra accuracy can be helpful....
>
>Just out of curiosity, can people out there in netland say:
>1) Which software systems do this [keep intermediate results this way]?

?? Most register allocators _should_ be doing this ... for the obvious
optimization reasons. On VAXFPA, IBM and UNIVAC machines this used to
be the case.

Tom Lahey's fortran for the pc did this. Example:

	sum = 0
	do i = 1, n
	   sum = x(i)*y(i)
	end do

produces the same answer when sum is dp or sp (x,y, sp..chosen to make
this interesting).

>2) How well it works?

Tom's compiler worked it well enough that some customer's complained.
So there is a compiler option that forces gratuitous stores to memory
to force the conversion to 32-bits.

Of course, this caused the results to be less accurate _AND_ slower.
there is no accounting for taste.

cheers




Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus