Walter Bright wrote:
> Don Clugston wrote:
>>> Since by definition a NaN is not equal to anything, including itself, I suppose it's a compiler bug?
>>
>> Definitely. I've seen that sort of behaviour before in VC++.
>> <cynic> Does anyone at Microsoft understand floating point arithmetic? </cynic>
> 
> At least up until VC6, it did not check the parity bit for floating point comparisons (the P bit is set if one of the operands is NaN). In fact, I know of no C++ compiler other than DMC++ that does this correctly.


I've been bitten by that before. Incorrect NaN support coupled with uninitialized variables is a deadly combination. Because negative numbers fill the stack with 0xFF bytes, it's relatively common for uninitialized floating-point stack variables to intermittently be NaN in release mode. The most-difficult-to-track-down bug I've ever had was a consequence of this.

> 
> VC dropping support for 80 bit long doubles is not an encouraging sign.
> 
> This is typical for C++ compiler vendors. Handling of NaN arguments to the math.h functions is routinely erratic and buggy. This can be traced back to the Standards committee, who failed to specify NaN behavior.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:e53c1b$11rl$1@digitaldaemon.com...

> VC dropping support for 80 bit long doubles is not an encouraging sign.

Well, correct me of I'm wrong, but aren't 80-bit floats being sort of "phased out" along with the x87 FP stack in favor of the new SSE2/3 instruction sets and 128-bit floats?  That might explain their decision.

For that matter, what's the plan for D when it comes to 128-bit floats?  A new type?  "quad"?

Jarrett Billingsley wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:e53c1b$11rl$1@digitaldaemon.com...
>> VC dropping support for 80 bit long doubles is not an encouraging sign.
> Well, correct me of I'm wrong, but aren't 80-bit floats being sort of "phased out" along with the x87 FP stack in favor of the new SSE2/3 instruction sets and 128-bit floats?  That might explain their decision.

I suspect it's the other way around. VC dropped 80 bit support long before those instructions were added.

> For that matter, what's the plan for D when it comes to 128-bit floats?  A new type?  "quad"? 

'real's are supposed to be the longest floating point type available on the hardware, so they'd be reals.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:e587a9$1k6q$1@digitaldaemon.com...

> 'real's are supposed to be the longest floating point type available on the hardware, so they'd be reals.

What about hardware that has both 80-bit _and_ 128-bit floats?  ;)

Jarrett Billingsley wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:e587a9$1k6q$1@digitaldaemon.com...
> 
>> 'real's are supposed to be the longest floating point type available on the hardware, so they'd be reals.
> 
> What about hardware that has both 80-bit _and_ 128-bit floats?  ;) 

There is already hardware that supports both 96-bit and 128-bit floats (sort of) -- it's called 64-bit Linux <g>.

I really think that 'real' should not be viewed as a built-in type, it should be a typedef, since that's how it behaves.
The built-in types could have really obscure names to discourage their use:
eg
typedef float80pad96 real;  // a Linux32 80-bit real
typedef float80pad128 real; // a Linux64 80-bit real
typedef float80pad80 real;  // a Win32 80-bit real

Or they could have even more obscure names, and equivalents to the above could be exposed only in std.stdint.
Name mangling would need to be sorted out, though.

However...

80-bit floats are really a poor man's 128 floats. If you had access to 128 bits, I don't think you'd ever want to use 80 bits, except for accessing legacy code.

I think we can safely assume that 128 bit floats will only exist on 64-bit OS-es. An 80-bit float on 64-bit Linux is binary compatible with a 128-bit IEEE float, the only difference is that the lowest bits in the mantissa are always zero.
So it should be possible to mix 80-bit and 128-bit Linux code without recompiling. 64-bit Windows is more of a problem.
And calling 32-bit Linux code from 64-bit Linux is definitely an issue (but in that case it's 128-bit vs 96-bit floats!).

Two questions:
(a) Are there any signs of Intel or AMD actually implementing 128 -bit floats?
(b) Are any compiler vendors using 80-bit or 128-bit floats in Win64 yet? How fixed is the ABI?

"Don Clugston" <dac@nospam.com.au> wrote in message news:e5e621$2232$1@digitaldaemon.com...

> I really think that 'real' should not be viewed as a built-in type, it
> should be a typedef, since that's how it behaves.
> The built-in types could have really obscure names to discourage their
> use:
> eg
> typedef float80pad96 real;  // a Linux32 80-bit real
> typedef float80pad128 real; // a Linux64 80-bit real
> typedef float80pad80 real;  // a Win32 80-bit real

I agree.

> (a) Are there any signs of Intel or AMD actually implementing 128 -bit floats?

Well, as far as I know (and as you probably already know and could have been on the designing committee for it), IEEE has already defined the 754 spec for 128-bit floats.  Considering that we've got (I suppose) 10-15 years before the 128-bit processor generation begins, and considering the ever-increasing demand for multimedia and floating-point performance, and considering Intel/AMD's desire to phase out x87 instructions in favor of the SSE/2/3/4 instructions (which have 32- and 64-bit float support already), I'd say the chances of 128-bit floats being created, maybe in just a couple years, is pretty high.  SSE5?

Jarrett Billingsley wrote:
> "Don Clugston" <dac@nospam.com.au> wrote in message news:e5e621$2232$1@digitaldaemon.com...
> 
>> I really think that 'real' should not be viewed as a built-in type, it should be a typedef, since that's how it behaves.
>> The built-in types could have really obscure names to discourage their use:
>> eg
>> typedef float80pad96 real;  // a Linux32 80-bit real
>> typedef float80pad128 real; // a Linux64 80-bit real
>> typedef float80pad80 real;  // a Win32 80-bit real
> 
> I agree.
> 
>> (a) Are there any signs of Intel or AMD actually implementing 128 -bit floats?
> 
> Well, as far as I know (and as you probably already know and could have been on the designing committee for it), 

LOL! I am just a humble cheesemaker.

IEEE has already defined the 754 spec
> for 128-bit floats.  Considering that we've got (I suppose) 10-15 years before the 128-bit processor generation begins, and considering the ever-increasing demand for multimedia and floating-point performance, and considering Intel/AMD's desire to phase out x87 instructions in favor of the SSE/2/3/4 instructions (which have 32- and 64-bit float support already), I'd say the chances of 128-bit floats being created, maybe in just a couple years, is pretty high.  SSE5? 

It seems clear that all future developments in floating point hardware will be driven by games, and not by science (that's already true of MMX and SSE). But maybe there is a market for 128-bit FP for graphics.

I just found a graphics card that is already using 128-bit floats:

http://www.firingsquad.com/hardware/radeon_9700/page2.asp

I *hope* they're using IEEE 754r.

Jarrett Billingsley wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:e587a9$1k6q$1@digitaldaemon.com...
> 
>> 'real's are supposed to be the longest floating point type available on the hardware, so they'd be reals.
> 
> What about hardware that has both 80-bit _and_ 128-bit floats?  ;) 

We'll add another basic type to D. But I don't know of any such hardware, or plans for any.

Don Clugston wrote:
> (b) Are any compiler vendors using 80-bit or 128-bit floats in Win64 yet? How fixed is the ABI?

My sources at Microsoft told me that 80 bit support was added to the core Win64 operating system (i.e. the task switcher). I haven't verified it personally.

Don Clugston wrote:
> LOL! I am just a humble cheesemaker.

Blessed are the cheesemakers!