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

[Walter Bright]

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.

> 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.