On 3 July 2014 14:51, Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 3 July 2014 at 11:21:34 UTC, Iain Buclaw via Digitalmars-d wrote:
>>
>> The spec should be clearer on that.  The language should respect the long
>> double ABI of the platform it is targeting
>> - so if the compiler is targeting a real=96bit system, but
>> the max supported on the  chip is 128bit, the compiler should
>> *still* map real to the 96bit long doubles, unless explicitly
>> told otherwise on the command-line.
>
>
> This would be a change in the standard, no?  "The long double ABI of the target platform" is not necessarily the same as the current definition of real as the largest hardware-supported floating-point type.
>
> I can't help but feel that this is another case where the definition of real in the D spec, and its practical use in the implementation, have wound up in conflict because of assumptions made relative to x86, where it's simply a nice coincidence that the largets hardware-supported FP and the long double type happen to be the same.

It's also a handy coincidence that for many platforms the targets largest supported FP and *double* type happen to be the same too.

On Thursday, 3 July 2014 at 06:56:20 UTC, Walter Bright wrote:
> On 7/2/2014 8:48 PM, Sean Kelly wrote:
>> I'm still unclear whether we're aiming for C interoperability or hardware
>> support though, based on Walter's remark about SPARC and PPC.  There, 'long
>> double' is represented differently but is not backed by specialized hardware, so
>> I'm guessing D would make 'real' 64-bits on these platforms and break
>> compatibility with C.  So... I guess we really do need a special alias for C
>> compatibility, and this can map to whatever intrinsic type the applicable
>> compiler supports for that platform.
>
> What is unclear about being able to call a C function declared as:
>
>     int foo(long double r);
>
> from D?

This:

On Thursday, 3 July 2014 at 00:03:47 UTC, Walter Bright wrote:
> On 7/2/2014 3:15 PM, Sean Kelly wrote:
>> On Wednesday, 2 July 2014 at 21:44:17 UTC, Walter Bright wrote:
>>> C long double == D real for 32 and 64 bit OSX, Linux, and FreeBSD.
>>
>> And it's 'double double' on PPC and 128 bit quad on SPARC.
>> Assuming D targets those platforms, what will be the behavior
>> there?
>
> Per the D spec, 'real' will be the longest type supported by the native hardware.

On 7/3/2014 3:49 AM, Jonathan M Davis via Digitalmars-d wrote:
> I don't think that there's anything unclear about that. The problem is that if
> real is supposed to be the largest hardware supported floating point type,
> then that doesn't necessarily match long double. It happens to on x86 and
> x86_64, but it doesn't on other architectures.

As it turns out, C compilers tend to use long double for that. So there's no issue. In any case, it's up to the person porting the D compiler to that platform to make these decisions.

For another case, D for Win64 maps real to 80 bits, despite VC++ mapping long double to 64 bits. This is compatible with the D spec, because you are still able to call C functions typed as "int foo(long double r)" because D's double works for that.

I think that some common sense on a case by case basis for each platform should work fine.

On 7/3/2014 8:36 AM, Sean Kelly wrote:
>> Per the D spec, 'real' will be the longest type supported by the native hardware.

It's not necessary that real be long double - but it is necessary that long double be callable from D.

Case in point: long double on Win64 is accessible with D's "double", but D also supports 80 bit "real".

On Thursday, 3 July 2014 at 19:47:32 UTC, Walter Bright wrote:
> On 7/3/2014 8:36 AM, Sean Kelly wrote:
>>> Per the D spec, 'real' will be the longest type supported by the native hardware.
>
> It's not necessary that real be long double - but it is necessary that long double be callable from D.
>
> Case in point: long double on Win64 is accessible with D's "double", but D also supports 80 bit "real".

That makes it seem like we are compatible by accident rather than by design.

On Thu, 03 Jul 2014 12:45:17 -0700
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 7/3/2014 3:49 AM, Jonathan M Davis via Digitalmars-d wrote:
> > I don't think that there's anything unclear about that. The problem is that if real is supposed to be the largest hardware supported floating point type, then that doesn't necessarily match long double. It happens to on x86 and x86_64, but it doesn't on other architectures.
>
> As it turns out, C compilers tend to use long double for that. So there's no issue. In any case, it's up to the person porting the D compiler to that platform to make these decisions.
>
> For another case, D for Win64 maps real to 80 bits, despite VC++ mapping long double to 64 bits. This is compatible with the D spec, because you are still able to call C functions typed as "int foo(long double r)" because D's double works for that.
>
> I think that some common sense on a case by case basis for each platform should work fine.

I'm fine with real varying from platform to platform depending on what makes sense for that platform, but I think that it should be clear what real is generally supposed to be (e.g. the largest floating point type that the hardware supports), but unless it's _guaranteed_ that real be the same as long double, I would strongly argue in favor of having an alias for long double rather than using real directly (much as it will likely be an alias to real in most cases). We already do that with c_long.

- Jonathan M Davis

On Thursday, 3 July 2014 at 21:01:43 UTC, Jonathan M Davis via
Digitalmars-d wrote:
>
> I'm fine with real varying from platform to platform depending on what makes sense for that platform, but I think that it should be clear what real is generally supposed to be (e.g. the largest floating point type that the hardware supports), but unless it's _guaranteed_ that real be the same as long double, I would strongly argue in favor of having an alias for long double rather than using real directly (much as it will likely be an alias to real in most cases). We already do that with c_long.

I'm inclined to agree.  From what's been said, I suspect that on
SPARC, 'real' would be an alias of 'double', and c_long_double
would be an alias of some intrinsic type provided by the
compiler, since there is no D equivalent for the IEEE 754
binary128 type.  The alternative, making c_long_double a struct
used for marshaling data into and out of the C format, doesn't
seem terribly appealing.

On Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote:
> On 7/2/2014 5:24 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> D is not even production ready,
>
> Of course it is.

Not by my definition of "production ready":

1. Not stable or up to date language spec.
2. Outstanding significant issues in the bug tracker.
3. No mature compiler.
4. No mature runtime.
5. No stable std library.
6. No entity/vendor that provides support/maintenance for a specific version of D for a specified period of time.

Would you use D for building software to ship with hardware appliances?

I would not.

On 3 July 2014 22:43, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote:
>>
>> On 7/2/2014 5:24 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>>
>>> D is not even production ready,
>>
>>
>> Of course it is.
>
>
> Not by my definition of "production ready":
>
> 1. Not stable or up to date language spec.
> 2. Outstanding significant issues in the bug tracker.
> 3. No mature compiler.
> 4. No mature runtime.
> 5. No stable std library.
> 6. No entity/vendor that provides support/maintenance for a specific version
> of D for a specified period of time.
>

You must know something I don't. :o)

On Thu, Jul 03, 2014 at 09:43:38PM +0000, via Digitalmars-d wrote:
> On Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote:
> >On 7/2/2014 5:24 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> >>D is not even production ready,
> >
> >Of course it is.
> 
> Not by my definition of "production ready":
[...]
> 2. Outstanding significant issues in the bug tracker.
[...]

I find this particular statement rather amusing. At my day job I work with "enterprise" software, which is currently running on dedicated hardware sold to major corporate customers worldwide. To say that the state of the bug tracker barely even begins to approach the state of D's bugtracker, would be the understatement of the century. We have so many outstanding bugs, ranging from minor to subtle-but-nasty to major design problems, that the PTBs have given up on trying to rein in the bug count, and have resorted to measures like closing bugs due to inactivity. The number of "outstanding significant issues" that get postponed past releases due to lack of resources, is enough to send chills down one's back, if he has any sense of pride in his work at all. Yet this bug-ridden software was deemed "production ready" (whatever that means), and is in fact running in mission-critical services on customer sites.

By comparison, the state of D's bug tracker looks a lot more promising.


T

-- 
Political correctness: socially-sanctioned hypocrisy.