March 07, 2007
On Wed, 07 Mar 2007 09:01:18 +0100, Frits van Bommel wrote:

> John Reimer wrote:
>> On Tue, 06 Mar 2007 01:16:07 -0500, David Friedman wrote:
>> 
>>> GDC now supports 64-bit targets! A new x86_64 Linux binary is available and the MacOS X binary supports x86_64 and ppc64.
> [snip]
>> 
>> I just realized that gdc still hasn't arrived at 1.0 yet even though the stated criteria for a gdc 1.0 was 64-bit support. :)
> 
> It was *a* stated criteria, not *the* stated criteria :P.
> In
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=D.gnu&article_id=2324
> David stated:
> ---
> I still want 64-bit and workable
> cross-compilation for a 1.00 release.
> ---
> 
> So I guess the next question would be "What's the status of cross-compilation?" :).
> 


Ah, I did miss the second criteria.  Oops. :)

-JJR
March 07, 2007
Anders F Björklund wrote:
> Sean Kelly wrote:
> 
>>>> Yeah that doesn't sound like a very attractive option.  Some of the later replies in the Darwin thread mention a compiler switch:
>>>>
>>>> http://lists.apple.com/archives/Darwin-development/2001/Jan/msg00471.html 
>>>>
>>>> Is that a possibility?  Or did that switch not make it into an actual release?
>>>
>>> There are two switches: -mlong-double-64 and -mlong-double-128,
>>> just that the second one ("double-double") is now the default...
>>
>> Oh I see.  That thread above suggested the opposite.  Could GDC simply key the size of real off this switch as well then?  If the point is for real to map to double-double, then it must be aware of it, correct?  I know it's not ideal to have the size of any variable change dynamically, but this seems like a case where doing so may actually be desirable.
> 
> The thread was old, things change. Especially: from GCC 3.3 to GCC 4.0
> http://developer.apple.com/releasenotes/DeveloperTools/RN-GCC4/index.html
> 
> "In previous releases of GCC, the long double type was just a synonym for double. GCC 4.0 now supports true long double. In GCC 4.0 long double is made up of two double parts, arranged so that the number of bits of precision is approximately twice that of double."
> 
> (this was for Apple GCC, but Linux PPC went through a similar change)
> 
> 
> 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.

> And since the D "real" type simply maps over to C/C++ "long double",
> it means that it will be either 64-bit, 80-bit or 128-bit. Varying.

We've got to keep that piece of lunacy out of D somehow. Could we define it as __longdouble or something? (Ideally only for PPC, so that error messages remain sensible on other platforms).

At least in D, we can static-if an alias or typedef on the basis of mant_dig.
March 07, 2007
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 :-)

>> And since the D "real" type simply maps over to C/C++ "long double",
>> it means that it will be either 64-bit, 80-bit or 128-bit. Varying.
> 
> We've got to keep that piece of lunacy out of D somehow. Could we define it as __longdouble or something? (Ideally only for PPC, so that error messages remain sensible on other platforms).
> 
> At least in D, we can static-if an alias or typedef on the basis of mant_dig.

I'll let David decide which one wins: D real === C long double, or
the definition of "largest hardware implemented floating point size"


But that that real.sizeof varies between D platforms, that is in the
very definition of the type. (similar to how int used to work, 16/32)

It'll be 10/12/16 bytes on Intel, and 8/16 on those other CPU types.
(i.e. 80-bits with padding on X86/x86_64, and 1 or 2 doubles on PPC)

--anders
March 07, 2007
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 :-)

*snicker*

>>> And since the D "real" type simply maps over to C/C++ "long double",
>>> it means that it will be either 64-bit, 80-bit or 128-bit. Varying.
>>
>> We've got to keep that piece of lunacy out of D somehow. Could we define it as __longdouble or something? (Ideally only for PPC, so that error messages remain sensible on other platforms).
>>
>> At least in D, we can static-if an alias or typedef on the basis of mant_dig.
> 
> I'll let David decide which one wins: D real === C long double, or
> the definition of "largest hardware implemented floating point size"

I think the salient point is "hardware implemented."  However, as David mentioned, C compatibility is important as well.  Perhaps it would be best to restrict real to the actual maximum size supported in hardware and to add an alias, typedef, struct, whatever, to allow C interop. This would be similar to what we already have to do for interfacing with C long/ulong across 32 and 64 bit platforms.  My only question here, then, is how translation might be performed between a 64 bit "hardware" real and a 128 bit "software" real?  And is this distinction truly useful?  Given the description of the current 128 bit doubles, I can't see ever wanting to use them.


Sean
March 07, 2007
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.

> 
>>> And since the D "real" type simply maps over to C/C++ "long double",
>>> it means that it will be either 64-bit, 80-bit or 128-bit. Varying.
>>
>> We've got to keep that piece of lunacy out of D somehow. Could we define it as __longdouble or something? (Ideally only for PPC, so that error messages remain sensible on other platforms).
>>
>> At least in D, we can static-if an alias or typedef on the basis of mant_dig.
> 
> 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.

Seriously, the viability of D as a numeric computing platform is at stake here.
March 07, 2007
Don Clugston wrote:
> 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.
> 
> Seriously, the viability of D as a numeric computing platform is at stake here.

I don't really understand the issues with the PPC 'double double', but:

1) real.sizeof is 10 on Win32, and 12 on Linux. This caused some (now fixed) compiler bugs, but shouldn't have affected any user code.

2) D floating point arithmetic is supposed to be IEEE 754. Some wacky real type for the PPC is going to cause grief and break code in irritating and unforeseeable ways.

3) The D implementation is allowed to evaluate floating point ops in higher precision than that specified by the type. FP algorithms should be coded to not break if more accurate answers are delivered.

4) I suggest supporting the wacky PPC double double with:
a) a special type, like __doubledouble, that is NOT real, ireal, or creal.
b) real should map to C's double, but still be a distinct type to the compiler
c) if doing __doubledouble is a pain as an inbuilt type, perhaps do it as a struct and a library type?
March 07, 2007
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 ?) But not on the DMD platform: Intel,
there it will have full 80-bit support (even if not too portable).

--anders
March 07, 2007
Walter Bright wrote:

> I don't really understand the issues with the PPC 'double double', but:
> 
> 1) real.sizeof is 10 on Win32, and 12 on Linux. This caused some (now fixed) compiler bugs, but shouldn't have affected any user code.

And real.sizeof is now 16 on Linux for X86_64 (even *more* padding)

> 2) D floating point arithmetic is supposed to be IEEE 754. Some wacky real type for the PPC is going to cause grief and break code in irritating and unforeseeable ways.

So basically we need to change PPC use of "long double" to "double"

> 3) The D implementation is allowed to evaluate floating point ops in higher precision than that specified by the type. FP algorithms should be coded to not break if more accurate answers are delivered.

But those higher evaluations should still be IEEE standard compatible.

> 4) I suggest supporting the wacky PPC double double with:
> a) a special type, like __doubledouble, that is NOT real, ireal, or creal.
> b) real should map to C's double, but still be a distinct type to the compiler
> c) if doing __doubledouble is a pain as an inbuilt type, perhaps do it as a struct and a library type?

That should pretty much settle it, then. GDC's "real" needs changing,
so that it uses C "double" on PPC even if "long double" is available.
(no idea how much work a __doubledouble or such D type would be to do,
but it is probably needed for interop with C "long double" routines...)

I think we can use the -mlong-double-64 option in the interim, minus
the C/C++ compatibility part (but not much uses "long double" on PPC)

--anders
March 07, 2007
Walter Bright wrote:
> Don Clugston wrote:
> 
>> 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.
>>
>> Seriously, the viability of D as a numeric computing platform is at stake here.
> 
> 
> I don't really understand the issues with the PPC 'double double', but:
> 
> 1) real.sizeof is 10 on Win32, and 12 on Linux. This caused some (now fixed) compiler bugs, but shouldn't have affected any user code.
> 
> 2) D floating point arithmetic is supposed to be IEEE 754. Some wacky real type for the PPC is going to cause grief and break code in irritating and unforeseeable ways.
> 

Alright.  Given the strict requirement for IEEE, D's real cannot be implemented as double+double.

> 3) The D implementation is allowed to evaluate floating point ops in higher precision than that specified by the type. FP algorithms should be coded to not break if more accurate answers are delivered.
> 
> 4) I suggest supporting the wacky PPC double double with:
> a) a special type, like __doubledouble, that is NOT real, ireal, or creal.
> b) real should map to C's double, but still be a distinct type to the compiler
> c) if doing __doubledouble is a pain as an inbuilt type, perhaps do it as a struct and a library type?

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
March 07, 2007
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?

How about giving it a leading _ ?