By: rwessel (robertwessel.delete@this.yahoo.com), August 22, 2013 12:41 pm
Room: Moderated Discussions
David Kanter (dkanter.delete@this.realworldtech.com) on August 22, 2013 1:02 am wrote:
> anonymou5 (no.delete@this.spam.com) on August 21, 2013 6:27 pm wrote:
> > David Kanter (dkanter.delete@this.realworldtech.com) on August 21, 2013 1:34 pm wrote:
> > > Yes, I would have eliminated x87 from long mode.
> >
> > Would you have added 80-bit EP support to XMM/SSE though?
>
> So I understand there are real benefits to the extra precision. In particular, it makes performance
> vs. accuracy a much more smooth trade-off. E.g., if you only need a few calculations in higher precision
> (say a final accumulate), you can get that accuracy without a huge penalty in performance.
It's a problem to eliminate features that are being used if you want to provide an upgrade path. 80 bit FP *is* directly exposed to the application, and by a fair number of programming languages (for example, non-Windows x86 C compilers often have "long double" as the 80-bit format). Second, much use can be made of the extended precision *internally*, where spill/rounding issues don't come into play. For example, computing many of the transcendentals is a great deal easier (and faster) if you have some extra precision to play with.
> However, I don't like it at all since it makes things numerically unstable depending on whether
> you need to spill to memory or not. It also makes validation and verification a pain.
This is a separate issue, and not one specific to 64-bit mode. It is a real flaw in x87, however. The real insanity of x87 is the stack architecture. The former problem could have been fixed with a few more op-codes (add, for example, add-single and add-double to the existing add-extended).
> Just to be clear, my long term goal would be to eliminate x87 entirely (and as many other
> nasty historical artifacts as possible). It's something that might not pay dividends immediately,
> but if the cost is low, the benefits in 5-10 years could be significant.
>
> Deprecating old and nasty stuff like x87 is fine, but you still end up with
> lots of control logic, microcode and other complexity in your design.
Again, the problem is providing an upgrade path. I think AMD would have been insane to drop x87 given the amount of use it still got. Even if many of those uses could be replaced with straight SSE2 code. Requiring significant structural changes is different than just (say) changing all the instruction encodings (which mostly impacts a small corner of the back end of compilers).
> anonymou5 (no.delete@this.spam.com) on August 21, 2013 6:27 pm wrote:
> > David Kanter (dkanter.delete@this.realworldtech.com) on August 21, 2013 1:34 pm wrote:
> > > Yes, I would have eliminated x87 from long mode.
> >
> > Would you have added 80-bit EP support to XMM/SSE though?
>
> So I understand there are real benefits to the extra precision. In particular, it makes performance
> vs. accuracy a much more smooth trade-off. E.g., if you only need a few calculations in higher precision
> (say a final accumulate), you can get that accuracy without a huge penalty in performance.
It's a problem to eliminate features that are being used if you want to provide an upgrade path. 80 bit FP *is* directly exposed to the application, and by a fair number of programming languages (for example, non-Windows x86 C compilers often have "long double" as the 80-bit format). Second, much use can be made of the extended precision *internally*, where spill/rounding issues don't come into play. For example, computing many of the transcendentals is a great deal easier (and faster) if you have some extra precision to play with.
> However, I don't like it at all since it makes things numerically unstable depending on whether
> you need to spill to memory or not. It also makes validation and verification a pain.
This is a separate issue, and not one specific to 64-bit mode. It is a real flaw in x87, however. The real insanity of x87 is the stack architecture. The former problem could have been fixed with a few more op-codes (add, for example, add-single and add-double to the existing add-extended).
> Just to be clear, my long term goal would be to eliminate x87 entirely (and as many other
> nasty historical artifacts as possible). It's something that might not pay dividends immediately,
> but if the cost is low, the benefits in 5-10 years could be significant.
>
> Deprecating old and nasty stuff like x87 is fine, but you still end up with
> lots of control logic, microcode and other complexity in your design.
Again, the problem is providing an upgrade path. I think AMD would have been insane to drop x87 given the amount of use it still got. Even if many of those uses could be replaced with straight SSE2 code. Requiring significant structural changes is different than just (say) changing all the instruction encodings (which mostly impacts a small corner of the back end of compilers).