[Issue 360] Compile-time floating-point calculations are sometimes inconsistent

[Don Clugston]

Walter Bright wrote:
> Don Clugston wrote:
>> Walter Bright wrote:
>> OK, you've convinced me. It needs to be better documented, though.
> 
> I agree with you and Bradley Smith on that.
> 
>>> P.S. I also did some digital electronic design work long ago. The 
>>> cardinal rule there was that since TTL devices got faster all the 
>>> time, and old slower TTL parts became unavailable, one designed so 
>>> that swapping in a faster chip would not cause the failure of the 
>>> system. Hence the rule that increasing the precision of a calculation 
>>> should not cause the program to fail <g>.
>>
>> I think it would be useful to specify more precisely what happens in 
>> constant folding. Eg, mention that all constant folding will be done 
>> in IEEE round-to-nearest, ties-to-even.
> 
> Yes.
> 
>> In the longer term, I've been wondering if the precision for real 
>> constants even needs to be the same as for the 'real' type. I can see 
>> some distinct benefits that would come if the precision of literals 
>> was defined to always be IEEE quadruple precision. Of course they'd 
>> always be rounded to 64 or 80-bit reals when the time came for them to 
>> actually be used.
> 
> I agree.

One consequence of that would be in the name mangling for floating point 
  constants in templates. Currently it's 20 hex characters, which only 
makes sense for a system with 80-bit reals; might be better to make it 
32 hex characters, even if the extra 12 are all '0'.

> 
>> Looking at the spec for the forthcoming IEEE 754R standard, and the 
>> state of SSE3 on AMD-64, it seems that Intel/AMD could very easily add 
>> a quadruple precision type (they already have 16 128 bit registers, 
>> two 64 bit mantissa units, and the quadruple exponent is the same as 
>> for x87. So I don't think it would require much silicon, and it would 
>> mean they could emulate the x87 stuff entirely on SSE). Some 
>> forward-compatibility things to consider in DMD 2.0; ignore for now.
> 
> I was disappointed in the AMD-64 because it didn't do 128 bit floats, in 
> fact, it relegated 80 bit floats to a backwater in the instruction set. 
> Few computer people seem to understand the value in high precision 
> floating point.

Intel seems to be better than AMD in this regard. Intel added an 82 bit 
floating point type to the Itanium so that it could do 80-bit hypot() 
without overflow (in fact, Itanium seems to have by far the best 
floating point support that I've seen); AMD's 3DNow! didn't even support 
subnormals, infinity, or NaN.