Anders F Björklund wrote:
>> ...
>> 
>> Seriously, the viability of D as a numeric computing platform is at stake here.
> 
> Only on the PowerPC platform, though. Maybe on SPARC too, not sure.
> (it might have real 128-bit ?) But not on the DMD platform: Intel,
> there it will have full 80-bit support (even if not too portable).
> 
> --anders

Make that x86... I read somewhere a few days ago that there IS no 80-bit real type on x86-64 machines; AMD basically went "80-bit?  Who the hell uses that junk?  Just use SSE you pack of anachronistic pansies!" and nuked the x87 in 64-bit code (you can still use it, but ONLY in 32-bit code).

And of course, what does SSE use?  IEEE 32-bit or 64-bit floats.

Ugh.  On the bright side, at least float and double are pretty safe :P

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> 
> Anders F Björklund wrote:
> 
>>>...
>>>
>>>Seriously, the viability of D as a numeric computing platform is at
>>>stake here.
>>
>>Only on the PowerPC platform, though. Maybe on SPARC too, not sure.
>>(it might have real 128-bit ?) But not on the DMD platform: Intel,
>>there it will have full 80-bit support (even if not too portable).
>>
>>--anders
> 
> 
> Make that x86... I read somewhere a few days ago that there IS no 80-bit
> real type on x86-64 machines; AMD basically went "80-bit?  Who the hell
> uses that junk?  Just use SSE you pack of anachronistic pansies!" and
> nuked the x87 in 64-bit code (you can still use it, but ONLY in 32-bit
> code).
> 
> And of course, what does SSE use?  IEEE 32-bit or 64-bit floats.
> 
> Ugh.  On the bright side, at least float and double are pretty safe :P
> 
> 	-- Daniel
> 

Yep. Read this:

http://blogs.msdn.com/ericflee/archive/2004/07/02/172206.aspx

It clearly states Win64 intended to eschew x87 register-saves (during a context switch), but may have had a change of heart?

AMD have been pretty clear about x86-64, in 64bit mode, having *no* support for x87 -- refer to page 20 of this: http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_AMD_GDC_2004_MW.pdf

That pretty much rules out the use of 80bit real on future platforms? Looks like things have to revert to double after all?

Daniel Keep wrote:
> 
> Anders F Björklund wrote:
>>> ...
>>>
>>> Seriously, the viability of D as a numeric computing platform is at
>>> stake here.
>> Only on the PowerPC platform, though. Maybe on SPARC too, not sure.
>> (it might have real 128-bit ?) But not on the DMD platform: Intel,
>> there it will have full 80-bit support (even if not too portable).
>>
>> --anders
> 
> Make that x86... I read somewhere a few days ago that there IS no 80-bit
> real type on x86-64 machines; AMD basically went "80-bit?  Who the hell
> uses that junk?  Just use SSE you pack of anachronistic pansies!" and
> nuked the x87 in 64-bit code (you can still use it, but ONLY in 32-bit
> code).

The 80 bit ops are available on the AMD-64 in 64 bit mode. But Microsoft's original plan for 80 bit reals was to not save them during a context switch, meaning you couldn't use them. I know a few people at Microsoft <g>, and made a pitch that the 80 bit regs should be saved, and they fixed it.

Anders F Björklund wrote:
> Don Clugston wrote:
> 
>>>>> Older versions of PPC operating systems used 64-bit for "long double",
>>>>> newer versions use 128-bit. Both are still in use, so we won't know.
>>>>
>>>> Ugh. That's really horrible.
>>>
>>> It's called progress :-)
>>
>> I was referring to the entire section, not just that line.
> 
> Seriously, there was a lot of effort put into supporting 128-bit
> long doubles - but I guess it was done with less emphasis on it
> being IEEE correct and handling exceptions then what D demands ?
> 
> The D spec should probably mention whether it absolutely requires
> the type to conform to the IEEE floating-point standard or not...
> i.e. whether it should just map over to C/C++ "long double" or not.
> 
>>> I'll let David decide which one wins: D real === C long double, or
>>> the definition of "largest hardware implemented floating point size"
>>
>> There's just no way D real can be equal to C long double in general, when the C long double is playing silly games. The only reason gcc can even do that, is that the C spec for floating point is ridiculously vague, and consequently no-one actually uses long double. To mimic it is to immediately break D's support for IEEE.
> 
> We can equate D "real" with C "long double", and just avoid using
> it on those platforms where it doesn't match the hardware size ?
> But then "real" would be a bad name for it, that I agree with...
> 
>> Seriously, the viability of D as a numeric computing platform is at stake here.
> 
> Only on the PowerPC platform, though. Maybe on SPARC too, not sure.
> (it might have real 128-bit ?) 

SPARC has true 128-bit IEEE reals, but they're not actually implemented (!). Actually the Linux 16-byte 80-bit reals are binary compatible with 128-bit IEEE reals (just that the final 128-80 bits are always set to zero).

But not on the DMD platform: Intel,
> there it will have full 80-bit support (even if not too portable).

My perspective is that I've been writing most of the Tango math library, trying to make it portable -- but it's just infeasible when this double+double type pops up. It just has almost nothing in common with the hardware real types!

> 
> --anders

Walter Bright wrote:
> Daniel Keep wrote:
> 
>>
>> Anders F Björklund wrote:
>>
>>>> ...
>>>>
>>>> Seriously, the viability of D as a numeric computing platform is at
>>>> stake here.
>>>
>>> Only on the PowerPC platform, though. Maybe on SPARC too, not sure.
>>> (it might have real 128-bit ?) But not on the DMD platform: Intel,
>>> there it will have full 80-bit support (even if not too portable).
>>>
>>> --anders
>>
>>
>> Make that x86... I read somewhere a few days ago that there IS no 80-bit
>> real type on x86-64 machines; AMD basically went "80-bit?  Who the hell
>> uses that junk?  Just use SSE you pack of anachronistic pansies!" and
>> nuked the x87 in 64-bit code (you can still use it, but ONLY in 32-bit
>> code).
> 
> 
> The 80 bit ops are available on the AMD-64 in 64 bit mode. But Microsoft's original plan for 80 bit reals was to not save them during a context switch, meaning you couldn't use them. I know a few people at Microsoft <g>, and made a pitch that the 80 bit regs should be saved, and they fixed it.


Looks like AMD adjusted their perspective and presentations at some point also. Page 211 of this document clarifies the current situation:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26569.pdf

However; x87 is referred to as "legacy" support. I guess we should hope that native 128bit FP will be supported by the time that legacy support is dropped?

David Friedman wrote:
> If I do implement it as a primitive type, how do you suggest I mangle it  and the imaginary/complex variants?  Should there be an 'implementation specific extension' mangle character?
> 
> David

I'm not following this discussion 100%, but if "double double" is only needed for interfacing with C, then why would you need the imaginary/complex variants?

L.

Lionello Lunesu wrote:
> David Friedman wrote:
>> If I do implement it as a primitive type, how do you suggest I mangle it  and the imaginary/complex variants?  Should there be an 'implementation specific extension' mangle character?
> 
> I'm not following this discussion 100%, but if "double double" is only needed for interfacing with C, then why would you need the imaginary/complex variants?

Google for "_Complex _Imaginary C99" (without the quotes).
C99 added some keywords to support complex & imaginary types.