On Tue, Mar 06, 2018 at 06:05:59PM +0000, jmh530 via Digitalmars-d-learn wrote:
> On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote:
> > [snip]
> > I'm not advocating for getting *rid* of 80-bit float support, but
> > only to make it *optional* rather than the default, as currently
> > done in std.math.
> Aren't there two issues: 1) std.math functions that cast to real to
> perform calculations, 2) the compiler sometimes converts things to
> real in the background when people don't want it to.
> Number 1 seems straightforward to fix. Introduce new versions of the
> std.math functions for float/double and the user can cast to real if
> the additional accuracy is necessary.
The fix itself may be straightforward, but how to do it without breaking
tons of existing code and provoking user backlash is the tricky part.
> Number 2 would require a compiler switch, I imagine.
It may not always be the compiler's fault. In the case of x87, it's the
hardware itself that internally promotes to 80-bit and truncates later.
IIRC, the original intent was that user code would only deal with
64-bit, and the 80-bit stuff would only happen inside the x87 (C, for
example, does not provide direct access to this type, except via vendor
extensions). However, due to the necessity to be able to save
intermediate computational states, there are instructions that can
load/extract 80-bit intermediate values to/from the x87, and eventually
people ended up just using these instructions for working with the
80-bit type directly. You can suppress the compiler from issuing these
instructions, but 64-bit doubles may still be internally converted by
the hardware to 80-bit intermediate values during computation.
But I suppose you could force the compiler to use SSE instructions for
double operations instead of x87, then it would bypass the 80-bit
intermediate values completely.
Being able to learn is a great learning; being able to unlearn is a greater