Community

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.