On 2 July 2014 19:58, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 2 July 2014 at 16:03:47 UTC, Iain Buclaw via Digitalmars-d wrote:
>>
>>
>> Only matters if you have to implement it in your backend
>
>
> You have to implement it in the backend if D requires strict IEEE754 conformance?
>

No, you don't.  At least I just let the gcc backend take care of whatever behaviours occur.  Which tend to be based around C as a baseline.


>> Vectors are treated differently from floats
>
>
> How can you then let the compiler vectorize? You can't. Meaning, your code will run very slow.
>

Easily - it does this for you so long as it determines that it is beneficial.

>> The ARM market is terrible, and it will certainly be the case that we *can't* have a one size fits all solution.  But in the standard libraries we can certainly keep strictly in line with the most conforming chips, so if you wish to support X you may do so in a platform-specific fork.
>
>
> I don't really understand the reasoning here. Is D Intel x86 specific?

Yes it is, more than you might realise.  I've been spending the last 4 years breaking it to be platform agnostic. :o)


Regards
Iain

On Wednesday, 2 July 2014 at 20:37:37 UTC, Walter Bright wrote:
> On 7/2/2014 1:53 AM, Don wrote:
>>
>> Ideally, I think we'd have a __real80 type. On x86 32 bit this would be the same as 'real', while on x86-64 __real80 would be available but probably 'real' would alias to double. But I'm a lot less certain about this.
>
> I'm afraid that would not only break most D programs, but also interoperability with C.

Could you explain this?  I didn't think we used 'real' to
interface with C at all.  We might need a type to match 'long
double' in C, but what that is is already exceedingly variable.
This would probably be another case for a special alias like we
have for c_long.

On 2 July 2014 21:37, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 7/2/2014 1:53 AM, Don wrote:
>>
>> Definitely, discarding excess precision is a crucial operation. C and C++
>> tried
>> to do it implicitly with "sequence points", but that kills optimisation
>> possibilities so much that compilers don't respect it. I think it's
>> actually
>> quite similar to write barriers in multithreaded programming. C got it
>> wrong,
>> but we're currently in an even worse situation because it doesn't
>> necessarily
>> happen at all.
>>
>> We need a builtin operation -- and not in std.math, this is as crucial as
>> addition, and it's purely a signal to the optimiser. It's very similar to
>> a
>> casting operation. I wonder if we can do it as an attribute?
>> .exact_float,
>> .restrict_float, .force_float, .spill_float or something similar?
>>
>> With D's current floating point semantics, it's actually impossible to
>> write
>> correct floating-point code. Everything that works right now, is
>> technically
>> only working by accident.
>>
>> But if we get this right, we can have very nice semantics for when things
>> like
>> FMA are allowed to happen -- essentially the optimiser would have free
>> reign
>> between these explicit discard_excess_precision sequence points.
>
>
> This is easily handled without language changes by putting a couple builtin
> functions in druntime - roundToFloat() and roundToDouble().
>
>
>
>> Ideally, I think we'd have a __real80 type. On x86 32 bit this would be
>> the same
>> as 'real', while on x86-64 __real80 would be available but probably 'real'
>> would
>> alias to double. But I'm a lot less certain about this.
>
>
> I'm afraid that would not only break most D programs, but also interoperability with C.

I think it could work with a very small selective list of operations.

ie:
- NegExp
- CmpExp
- CallExp to core.math intrinsics.


Regards
Iain.

On 7/2/2014 2:33 PM, Sean Kelly wrote:
> On Wednesday, 2 July 2014 at 20:37:37 UTC, Walter Bright wrote:
>> I'm afraid that would not only break most D programs, but also
>> interoperability with C.
>
> Could you explain this?  I didn't think we used 'real' to
> interface with C at all.  We might need a type to match 'long
> double' in C, but what that is is already exceedingly variable.
> This would probably be another case for a special alias like we
> have for c_long.


C long double == D real for 32 and 64 bit OSX, Linux, and FreeBSD.

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.

On Wednesday, 2 July 2014 at 21:44:17 UTC, Walter Bright wrote:
> On 7/2/2014 2:33 PM, Sean Kelly wrote:
>> On Wednesday, 2 July 2014 at 20:37:37 UTC, Walter Bright wrote:
>>> I'm afraid that would not only break most D programs, but also
>>> interoperability with C.
>>
>> Could you explain this?  I didn't think we used 'real' to
>> interface with C at all.  We might need a type to match 'long
>> double' in C, but what that is is already exceedingly variable.
>> This would probably be another case for a special alias like we
>> have for c_long.
>
> 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?

 From my perspective, it seems like 'real' in D is utterly
non-portable given its definition.  I can see maybe using it in
some cases if I knew I was targeting a specific architecture
where the added precision was helpful, but for general purpose
programming I'd always either use 'double' or some library-based
type for extended precision, simply to have some assurance that
my result would be predictable.  Am I wrong in this?

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.


>   From my perspective, it seems like 'real' in D is utterly
> non-portable given its definition.  I can see maybe using it in
> some cases if I knew I was targeting a specific architecture
> where the added precision was helpful, but for general purpose
> programming I'd always either use 'double' or some library-based
> type for extended precision, simply to have some assurance that
> my result would be predictable.  Am I wrong in this?

D is a systems programming language. That means it should have access to the hardware supported types. Portability is not the only goal - especially if that means "least common denominator". People pay money for more powerful chips, and they'll want to use them.

Not only that, a marquee feature of D is interoperability with C. We'd need an AWFULLY good reason to throw that under the bus.

On 7/2/2014 2:28 PM, Iain Buclaw via Digitalmars-d wrote:
> On 2 July 2014 19:58, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> I don't really understand the reasoning here. Is D Intel x86 specific?
> Yes it is, more than you might realise.  I've been spending the last 4
> years breaking it to be platform agnostic. :o)

I think you're conflating dmd with D.

And IEEE 754 is a standard.

On Wed, Jul 02, 2014 at 05:03:47PM -0700, Walter Bright via Digitalmars-d wrote: [...]
> D is a systems programming language. That means it should have access to the hardware supported types. Portability is not the only goal - especially if that means "least common denominator". People pay money for more powerful chips, and they'll want to use them.

What should we do in the case of hardware that offers strange hardware types, like a hypothetical 48-bit floating point type? Should D offer a built-in type for that purpose, even if it only exists on a single chip that's used by 0.01% of the community?


> Not only that, a marquee feature of D is interoperability with C. We'd need an AWFULLY good reason to throw that under the bus.

I'm not sure I understand how removing support 80-bit floats hurts interoperability with C? I thought none of the standard C float types map to the x87 80-bit float?

(I'm not opposed to keeping real as 80-bit on x87, but I just don't understand what this has to do with C interoperability.)


T

-- 
In order to understand recursion you must first understand recursion.

On Thursday, 3 July 2014 at 01:13:13 UTC, H. S. Teoh via Digitalmars-d wrote:
>
> I'm not sure I understand how removing support 80-bit floats hurts interoperability with C? I thought none of the standard C float types map to the x87 80-bit float?

The C spec never says anything specific about representation because it's meant to target anything, but the x86 and AMD64 ABIs basically say that "long double" is 80-bit for calculations.  The x86 spec says that the type is stored in 96 bits though, and the AMD64 spec says they're stored in 128 bits for alignment purposes.

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.