Yes, ARM D support is really important.

https://josephscott.org/archives/2013/12/is-facebook-planning-a-move-to-arm-based-servers/

BTW, it might be a good idea to also target ARM64, while we're at it...

On Friday, 13 December 2013 at 17:18:30 UTC, Luís Marques wrote:
> Yes, ARM D support is really important.
>
> https://josephscott.org/archives/2013/12/is-facebook-planning-a-move-to-arm-based-servers/

It also came out today that Google is thinking about designing custom ARM chips to put in their servers:

http://www.theverge.com/2013/12/13/5206420/google-arm-chips-for-servers-rumor

> BTW, it might be a good idea to also target ARM64, while we're at it...

Phobos seems to be largely arch-independent.  Druntime has some limited ARM support and Martin committed the first druntime patch that references AARCH64 a couple months back: :)

https://github.com/D-Programming-Language/druntime/commit/6803132b0d76ef895718fe8f0e835bf8dc3d0ecf#diff-4c8de49e7eb91f21fda73e8133fea05aR219

The missing piece is that dmd doesn't have an ARM backend.  The other D compilers do however, and Apple plans to open-source their custom AARCH64 backend and merge it into the existing one in llvm soon:

http://www.phoronix.com/scan.php?page=news_item&px=MTQ1ODM

So I imagine D users will have ARM/AARCH64 support at some point next year, depending on how long it takes to put all the pieces together.

On Dec 13, 2013 8:40 PM, "Joakim" <joakim@airpost.net> wrote:
>
> On Friday, 13 December 2013 at 17:18:30 UTC, Luís Marques wrote:
>>
>> Yes, ARM D support is really important.
>>
>>
https://josephscott.org/archives/2013/12/is-facebook-planning-a-move-to-arm-based-servers/
>
>
> It also came out today that Google is thinking about designing custom ARM
chips to put in their servers:
>
>
http://www.theverge.com/2013/12/13/5206420/google-arm-chips-for-servers-rumor
>
>
>> BTW, it might be a good idea to also target ARM64, while we're at it...
>
>
> Phobos seems to be largely arch-independent.  Druntime has some limited
ARM support and Martin committed the first druntime patch that references AARCH64 a couple months back: :)
>
>
https://github.com/D-Programming-Language/druntime/commit/6803132b0d76ef895718fe8f0e835bf8dc3d0ecf#diff-4c8de49e7eb91f21fda73e8133fea05aR219
>
> The missing piece is that dmd doesn't have an ARM backend.  The other D
compilers do however, and Apple plans to open-source their custom AARCH64 backend and merge it into the existing one in llvm soon:
>
> http://www.phoronix.com/scan.php?page=news_item&px=MTQ1ODM
>
> So I imagine D users will have ARM/AARCH64 support at some point next
year, depending on how long it takes to put all the pieces together.

And assuming someone doesn't write some new x86 centric module to replace the well tested, architecture independent implementation just because you can't use it in ctfe.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 2 December 2013 at 18:35:36 UTC, Rainer Schuetze wrote:
> On 02.12.2013 10:36, Joakim wrote:
>> Where is this "implicit include directive?"  It's confusing because "dmd
>> -v" shows the exact same linker command being run whether that "extern
>> (C)" is there before main or not.
>
> The compiler embeds it into the object file if code for "D main" is generated. The respective code is around line 742, glue.c.
Thanks, I see it.

> IIRC it is not possible to embed a linker directive into an ELF object file, so it must always be specified on the command line. Maybe the linker is looking for libphobos2.a in the wrong directories?
The problem was that I was specifying libphobos2.a _before_ the object file that dmd compiled when linking and the linker order was biting me.  It worked fine with the wrong linker order as long as I didn't reference symbols like stderr from druntime, because it was getting stdc function symbols from libc anyway, but would crap out when the stderr symbol was needed from druntime.  As usual, the problem was user error. :)

I just got a basic D program running with a patched druntime on Android/x86. :) I was also able to compile and run sieve.d from the D samples, after replacing std.stdio.writefln with core.stdc.stdio.printf and moving the flags declaration inside main.  It would segfault at "flags[]=true" if I didn't move that declaration inside, so there are obviously still some scoping issues, perhaps because I haven't ported all of druntime to Android yet, only about halfway done.

> I just got a basic D program running with a patched druntime on Android/x86. :) I was also able to compile and run sieve.d from the D samples, after replacing std.stdio.writefln with core.stdc.stdio.printf and moving the flags declaration inside main.  It would segfault at "flags[]=true" if I didn't move that declaration inside, so there are obviously still some scoping issues, perhaps because I haven't ported all of druntime to Android yet, only about halfway done.

I finished porting most of druntime to Android/x86 and have started trying to run the tests: I just got 31 out of 38 druntime modules' unit tests to pass. :)

I figured out the segfault mentioned above was because TLS is done differently on Android- flags[] is a global when outside main and thread-local by default as a result, adding a shared attribute makes it work again- and I was getting a lot of segfaults on the unit tests for the same reason.  After making all the simple globals in the unit tests, like cpuid in rt.arrayfloat/int/etc., into shared variables, only 8 modules' unittests segfault, one after passing.

Bionic doesn't support __thread for TLS, but it does let you use the pthread_key_(create|delete)/pthread_(set|get)specific APIs, just as druntime does on OS X.  Here's the bionic implementation:

https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_key.cpp

I haven't completely grasped TLS and how it's done on OS X yet, but I get the sense I'll have to modify dmd a little to get TLS working with bionic.  It appears that Martin and Johannes have looked into this before, so if you two have any feedback, let me know.

I'm hoping TLS is the last remaining piece for druntime to be finished porting to Android/x86, then I want to try Phobos, which I'm guessing shouldn't be as bad.

On 2013-12-28 23:21, Joakim wrote:

> I haven't completely grasped TLS and how it's done on OS X yet, but I
> get the sense I'll have to modify dmd a little to get TLS working with
> bionic.  It appears that Martin and Johannes have looked into this
> before, so if you two have any feedback, let me know.

Yes, you need to modify dmd. On Mac OS X every time a TLS variable is accessed the compiler inserts a call to ___tls_get_addr which is declared in rt.sections_osx in druntime.

-- 
/Jacob Carlborg

On Saturday, 28 December 2013 at 22:21:46 UTC, Joakim wrote:
> I finished porting most of druntime to Android/x86 and have started trying to run the tests: I just got 31 out of 38 druntime modules' unit tests to pass. :)
>
> I figured out the segfault mentioned above was because TLS is done differently on Android- flags[] is a global when outside main and thread-local by default as a result, adding a shared attribute makes it work again- and I was getting a lot of segfaults on the unit tests for the same reason.  After making all the simple globals in the unit tests, like cpuid in rt.arrayfloat/int/etc., into shared variables, only 8 modules' unittests segfault, one after passing.
>
> Bionic doesn't support __thread for TLS, but it does let you use the pthread_key_(create|delete)/pthread_(set|get)specific APIs, just as druntime does on OS X.  Here's the bionic implementation:
>
> https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_key.cpp
>
> I haven't completely grasped TLS and how it's done on OS X yet, but I get the sense I'll have to modify dmd a little to get TLS working with bionic.  It appears that Martin and Johannes have looked into this before, so if you two have any feedback, let me know.
>
> I'm hoping TLS is the last remaining piece for druntime to be finished porting to Android/x86, then I want to try Phobos, which I'm guessing shouldn't be as bad.
Been awhile since I updated on the Android effort: I'm now able to get all 38 druntime modules' unit tests to pass on Android/x86... under somewhat random conditions.  It's finicky and some of the tests start failing and many segfaulting on exit, as mentioned before, if I make minor changes to the unit tests, like changing some TLS globals to shared.  I'm guessing this is because I don't really have TLS working yet, I'm just taking advantage of the fact that the baked-in TLS in linux kinda sorta still works on Android.

As long as it's local-exec, uninitialized TLS mostly works if it's less than 4-5 KB, while initialized TLS doesn't get initialized correctly.  Of course, it's possible that I'm hitting some other codegen incompatibility altogether, unrelated to TLS, but the fact that it sometimes works depending on the number of TLS variables makes me think it's a TLS issue.  I also got a bit more than half of the Phobos unit tests to pass, with a lot of seg faults there too.

Android is going to need a packed TLS approach, similar to what Walter implemented for OS X with dmd:

http://www.drdobbs.com/architecture-and-design/implementing-thread-local-storage-on-os/228701185

I've been looking into doing something similar for ELF, but this is the first time hacking on a compiler for me.  If someone else more familiar with dmd or ldc could put packed TLS for ELF together more quickly, that would certainly speed things up.  If not, I'll have something together eventually. ;)

On Friday, 21 March 2014 at 19:59:41 UTC, Joakim wrote:
> Been awhile since I updated on the Android effort: I'm now able to get all 38 druntime modules' unit tests to pass on Android/x86... under somewhat random conditions.  It's finicky and some of the tests start failing and many segfaulting on exit, as mentioned before, if I make minor changes to the unit tests, like changing some TLS globals to shared.  I'm guessing this is because I don't really have TLS working yet, I'm just taking advantage of the fact that the baked-in TLS in linux kinda sorta still works on Android.
>
> As long as it's local-exec, uninitialized TLS mostly works if it's less than 4-5 KB, while initialized TLS doesn't get initialized correctly.  Of course, it's possible that I'm hitting some other codegen incompatibility altogether, unrelated to TLS, but the fact that it sometimes works depending on the number of TLS variables makes me think it's a TLS issue.  I also got a bit more than half of the Phobos unit tests to pass, with a lot of seg faults there too.
>
> Android is going to need a packed TLS approach, similar to what Walter implemented for OS X with dmd:
>
> http://www.drdobbs.com/architecture-and-design/implementing-thread-local-storage-on-os/228701185
>
> I've been looking into doing something similar for ELF, but this is the first time hacking on a compiler for me.  If someone else more familiar with dmd or ldc could put packed TLS for ELF together more quickly, that would certainly speed things up.  If not, I'll have something together eventually. ;)

Alright, finally hacked dmd to produce something like packed TLS for ELF.  I just ran the druntime unit tests on Android/x86 and all 38 modules passed, :) even after changing the number of TLS variables a couple times, which was causing segfaults with the native TLS before.  I'll try running the phobos unit tests next, then building a sample Android/x86 D app/apk, ie the kind you can actually install on Android.

On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
> I know, I know, this question has been asked many times before. But it came up in a meeting the other day: is there any work being done on making D an ARM citizen so that _non-trivial_ D code can be ported to smartphones and the like? If so, what it the rough time frame?

I have few small/toy D apps running on my ODROID-U2 . They are compiled using latest GDC (4.8 branch). It all works fine. Yeah, phobos is 40+MiB big, but I have gibibytes free on emmc card! ;)

On 23/04/14 13:39, Joakim wrote:

> Alright, finally hacked dmd to produce something like packed TLS for
> ELF.  I just ran the druntime unit tests on Android/x86 and all 38
> modules passed, :) even after changing the number of TLS variables a
> couple times, which was causing segfaults with the native TLS before.
> I'll try running the phobos unit tests next, then building a sample
> Android/x86 D app/apk, ie the kind you can actually install on Android.

That's awesome :)

-- 
/Jacob Carlborg