On 1 July 2014 20:36, via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Tuesday, 1 July 2014 at 16:58:55 UTC, Walter Bright wrote: >> >> Click on "compiling for strict IEEE conformance" > > > It also states that compliance affect performance. > > >>> not IEEE754 compliant. VPF is almost compliant, but does not support >>> subnormal >>> numbers and flush them to zero. Which can be a disaster… >> >> >> It wouldn't be any different if the D spec says "floating point is, ya >> know, whatevah". You can't fix stuff like this in the spec. > > > Well, the difference is that you can make VPF mostly compliant, but that > means you trap subnormal numbers and fix it in software. Which affects > performance. > > If the specs require IEEE754 compliance then you default to software > emulation and have to turn it off through compiler switches. > > Here is another example: the parallella Coprocessor from Adapteva: > > «The CPU is compatible with the IEEE-754 single-precision format, with the > following > exceptions: > - No support for inexact flags. > - NAN inputs generate an invalid exception and return a quiet NAN. When one > or both of the > inputs are NANs, the sign bit of the operation is set as an XOR of the signs > of the input sign > bits. > - Denormal operands are flushed to zero when input to a computation unit and > do not generate > an underflow exception. Any denormal or underflow result from an arithmetic > operation is > flushed to zero and an underflow exception is generated. > - Round-to-±infinity is not supported.» >
The crucial thing here is that the layout of float/double types are IEEE 754 are compatible. :) These behaviours you describe only affect the FP control functions in std.math, which are the only thing platform specific, and can only be written in inline assembly anyway... Regards Iain