View mode: basic / threaded / horizontal-split · Log in · Help
March 08, 2007
Re: GDC release 0.23
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/
March 08, 2007
Re: GDC release 0.23
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?
March 08, 2007
Re: GDC release 0.23
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.
March 08, 2007
Re: GDC release 0.23
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
March 08, 2007
Re: GDC release 0.23
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?
March 08, 2007
Re: GDC release 0.23
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.
March 08, 2007
Re: GDC release 0.23
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.
Next ›   Last »
2 3 4 5 6
Top | Discussion index | About this forum | D home