Article: AMD's Jaguar Microarchitecture
By: Wilco (Wilco.Dijkstra.delete@this.ntlworld.com), April 7, 2014 2:27 am
Room: Moderated Discussions
Michael S (already5chosen.delete@this.yahoo.com) on April 7, 2014 2:34 am wrote:
> TREZA (no.delete@this.ema.il) on April 6, 2014 3:47 pm wrote:
> > Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on April 6, 2014 2:48 pm wrote:
> > > Extended precision as implemented in x87 is a huge mess. It even causes 32 and 64-bit
> > > FP to return inconsistent and incorrect results. Nowadays it means 128-bits, not 80.
> > >
> > A mess because there is no separate instructions like FADDs, FADDd,
> > FADDe, which makes programs prone to double rounding ?
>
> There are no separate instructions, but there is precision control field in the control
> word, so, as long as you don't change precision very often, you (or your compiler)
> can avoid double rounding at very relatively small performance penalty.
Changing precision is expensive, and if you have code with both float and double, you need to change precision all the time (and you cannot guarantee whether a function you called changed it unless you change the ABI to say that every function must save/restore the precision).
> The real problem is more exotic - x87 precision control can reduce the precision of
> mantissa, but it can't reduce the range of exponent. So, results of x87 computations
> with single or double precision remain the same as specified by IEEE only as long as
> you stay within official range. Which sounds nearly impossible in practice.
You can store to memory after every operation to get the exponent right - this is still not IEEE compliant as denormals suffer from double rounding. Of course doing this causes another performance penalty but at least it gives more consistent results than variables whose values suddenly change due to needing to be spilled to memory by the compiler.
Basically you cannot get IEEE results from x87. Quite ironic since x87 was supposed to be the first IEEE implementation...
> > The Motorola 68881/2 did not have that problem, IIRC.
> > (The whole x87 instruction set is a joke anyway)
And ARM's FPA did get it right too. The broken stack implementation is another idiotic aspect of x87 indeed.
Wilco
> TREZA (no.delete@this.ema.il) on April 6, 2014 3:47 pm wrote:
> > Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on April 6, 2014 2:48 pm wrote:
> > > Extended precision as implemented in x87 is a huge mess. It even causes 32 and 64-bit
> > > FP to return inconsistent and incorrect results. Nowadays it means 128-bits, not 80.
> > >
> > A mess because there is no separate instructions like FADDs, FADDd,
> > FADDe, which makes programs prone to double rounding ?
>
> There are no separate instructions, but there is precision control field in the control
> word, so, as long as you don't change precision very often, you (or your compiler)
> can avoid double rounding at very relatively small performance penalty.
Changing precision is expensive, and if you have code with both float and double, you need to change precision all the time (and you cannot guarantee whether a function you called changed it unless you change the ABI to say that every function must save/restore the precision).
> The real problem is more exotic - x87 precision control can reduce the precision of
> mantissa, but it can't reduce the range of exponent. So, results of x87 computations
> with single or double precision remain the same as specified by IEEE only as long as
> you stay within official range. Which sounds nearly impossible in practice.
You can store to memory after every operation to get the exponent right - this is still not IEEE compliant as denormals suffer from double rounding. Of course doing this causes another performance penalty but at least it gives more consistent results than variables whose values suddenly change due to needing to be spilled to memory by the compiler.
Basically you cannot get IEEE results from x87. Quite ironic since x87 was supposed to be the first IEEE implementation...
> > The Motorola 68881/2 did not have that problem, IIRC.
> > (The whole x87 instruction set is a joke anyway)
And ARM's FPA did get it right too. The broken stack implementation is another idiotic aspect of x87 indeed.
Wilco