On 9 August 2015 at 09:53, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 8/9/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
>
>> What about intrinsics?
>>
>>
>> https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630
>>
>
> There isn't a simd cosine instruction, so making cos(double) builtin accomplishes nothing. However, the casting in those functions go away when code is generated.
>
> For example:
>
>   import std.math;
>   double foo(double d) {
>     return cos(d);
>   }
>
> generates:
>
>   _D3foo3fooFdZd:
>                 fld     qword ptr 4[ESP]
>                 fcos
>                 ret     8
>

This is on Windows?  I'm not seeing this on Linux.  http://goo.gl/58yhwU

On 8/9/2015 1:05 AM, Iain Buclaw via Digitalmars-d wrote:
> This is on Windows?  I'm not seeing this on Linux. http://goo.gl/58yhwU

You're seeing that on Linux because doubles are passed/returned in XMM0 on Linux, and the only way to load XMM0 into the x87 is to pass it through a memory location. There's still no casting to/from real, even in that asm code.

On 8/9/2015 1:11 AM, Walter Bright wrote:
> You're seeing that on Linux because doubles are passed/returned in XMM0 on
> Linux, and the only way to load XMM0 into the x87 is to pass it through a memory
> location. There's still no casting to/from real, even in that asm code.

BTW, if you want to suggest faster emitted code for cos(float) and cos(double), I'm game! Fire away!

Am Sun, 9 Aug 2015 01:05:35 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> I don't understand your question. On Linux, TLS data is inserted into the same section that gcc puts it. On OSX, where gcc didn't support TLS, dmd did create it into a data segment. Every time a new thread was created, druntime would malloc a chunk of data, and copy that data segment into it to initialize it. Then it would save a pointer to the malloced data in the thread data structure.
> 
> Accessing the OSX TLS involved finding the thread data structure for the current thread, and getting the pointer to the TLS malloced data, and adding the offset of the symbol to it.
> 

Do you support shared libraries on OSX with that emulated TLS system for all use cases? What if library A want to access a exported TLS variable in library B? How do you:

1) Find the library the imported symbol is exported from (libraryB)
2) Find the TLS block for that library
3) Find the offset in that TLS block

> The only reason a new data section was required was so that all the TLS data from all the object modules would be adjacent. It's the only way to do it.
> 

That statement is too broad to be true ;-) GCC's emulated TLS doesn't
have adjacent memory for TLS variables and it works fine with D
(and the GC). It is a little bit slower than if we had adjacent memory.
OTOH this approach works with all kinds of shared libraries and
requires very little system specific code (only need some pthread tls
mechanism). And it is compatible with GCCs emulated TLS, so you can
even have extern TLS variables shared between C and D with emutls.

Am Sun, 9 Aug 2015 00:32:00 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 8/8/2015 11:36 PM, Tofu Ninja wrote:
> > On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
> >> dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower.
> >
> > I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's "not made here" syndrome strikes again!
> 
> There's pretty much no talent focused on the dmd back end. I do most of the (very) occasional bug fixes, and sometimes Martin or Daniel correct something, and that's about it.
> 
> The idea that it is sucking up resources is incorrect.
> 

The DMD devs aren't working on the backend, but the GDC and LDC are neither ;-) He's talking about the glue layer.

DMD has the advantage that whenever a frontend pull request requires glue layer changes you get at and once by the contributor. But for LDC and GDC the glue layer changes have to be implemented by GDC/LDC devs.

On 8/9/2015 2:04 AM, Johannes Pfau wrote:
> That statement is too broad to be true ;-) GCC's emulated TLS doesn't
> have adjacent memory for TLS variables and it works fine with D
> (and the GC). It is a little bit slower than if we had adjacent memory.
> OTOH this approach works with all kinds of shared libraries and
> requires very little system specific code (only need some pthread tls
> mechanism). And it is compatible with GCCs emulated TLS, so you can
> even have extern TLS variables shared between C and D with emutls.

The reason I did the special support for TLS on OSX is because gcc at the time did not support TLS in any way shape or form. Now that it does, dmd should change to do it the same way.

On 8/9/2015 2:07 AM, Johannes Pfau wrote:
> DMD has the advantage that whenever a frontend pull request requires
> glue layer changes you get at and once by the contributor. But for
> LDC and GDC the glue layer changes have to be implemented by GDC/LDC
> devs.

If LDC were the default, then the GDC devs would still have to do the same work.

On 9 August 2015 at 11:07, Johannes Pfau via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> Am Sun, 9 Aug 2015 00:32:00 -0700
> schrieb Walter Bright <newshound2@digitalmars.com>:
>
> > On 8/8/2015 11:36 PM, Tofu Ninja wrote:
> > > On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
> > >> dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower.
> > >
> > > I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's "not made here" syndrome strikes again!
> >
> > There's pretty much no talent focused on the dmd back end. I do most of the (very) occasional bug fixes, and sometimes Martin or Daniel correct something, and that's about it.
> >
> > The idea that it is sucking up resources is incorrect.
> >
>
> The DMD devs aren't working on the backend, but the GDC and LDC are neither ;-) He's talking about the glue layer.
>
> DMD has the advantage that whenever a frontend pull request requires glue layer changes you get at and once by the contributor. But for LDC and GDC the glue layer changes have to be implemented by GDC/LDC devs.
>

I think that is more of a problem with length of development + number of contributors/changes.

For instance, when it was just Walter committing changes, the number of "fixed" bugs was of a reasonable number such that I could have gone through them all and tested them within a day (this is back when the D2 testsuite was private and I had no way other way to track whether or not codegen changes were required).

Now we have the testsuite, which seems to be a good enough gauge for finding problems.  However if there's been a change (eg: refactor) between what codegen is lowered in the frontend vs. glue, then it becomes a commit hunt trawling through thousands of changes to work out which one is relevant to the new wrong-code-on-previously-working test.  One day turns into a week, turns into a month, turns into half a year.

Iain.

On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:
>>
>> [...]
>
>
> Don't worry about it!
> But I see your point. All we can do is truck on.
>
> You will enjoy my latest blog post I think[0].
> I reiterate one thing, if it's hard, it's probably wrong. So, lets make
> things easy. Build a wide range a libraries to make certain programs easy to
> write.
>
> Something I'd like to say is that I do really appreciate you and your work.
> If I could I would love to learn from you directly. I cannot give a higher
> respect or appreciation then that.
> Even though it is hard for you to still be here, I hope you do continue to
> help D grow. This is a good community, we just need time before real
> adoption. E.g. we are only just now starting to unify projects.

Cheers, but don't get me wrong; I've barely contributed anything of
value other than advocacy and little bits and pieces here and there. I
don't deserve any credit, I just complain about things that make it
impossible for me to get on with my work.
You'll know D is on good shape when you don't hear a peep from me anymore ;)

Am Sun, 9 Aug 2015 02:17:11 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 8/9/2015 2:07 AM, Johannes Pfau wrote:
> > DMD has the advantage that whenever a frontend pull request requires glue layer changes you get at and once by the contributor. But for LDC and GDC the glue layer changes have to be implemented by GDC/LDC devs.
> 
> If LDC were the default, then the GDC devs would still have to do the same work.
> 

Sure. I'm not arguing that LDC or GDC should be the default, just
wanted to explain why we could really need some more contributors for GDC/LDC ;-)