www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ehem, ARM

reply "Chris" <wendlec tcd.ie> writes:
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?
Nov 14 2013
next sibling parent reply "eles" <eles eles.com> writes:
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?


A D.arm or D.ports group?
Nov 14 2013
parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 14 November 2013 at 15:31:25 UTC, eles wrote:

 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?


 A D.arm or D.ports group?


Yes. Mobile devices cannot be ignored.
Nov 14 2013
prev sibling next sibling parent reply "Kai Nacke" <kai redstar.de> writes:
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?


Hi Chris!

LDC can generate binaries for ARM but still has a major bug which 
prevents working exception handling. My new developer board 
arrived this week so I hope to solve this issue soon.

But this is only half of the story. My target is Linux/ARM which 
is already supported by druntime/phobos. If you target a 
smartphone then you also have to add Android or iOS support to 
druntime/phobos. I don't know if somebody is working on this 
topic.

Regards,
Kai
Nov 14 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 14 November 2013 at 16:14:16 UTC, Kai Nacke wrote:

 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?


 Hi Chris!

 LDC can generate binaries for ARM but still has a major bug 
 which prevents working exception handling. My new developer 
 board arrived this week so I hope to solve this issue soon.

 But this is only half of the story. My target is Linux/ARM 
 which is already supported by druntime/phobos. If you target a 
 smartphone then you also have to add Android or iOS support to 
 druntime/phobos. I don't know if somebody is working on this 
 topic.

 Regards,
 Kai


Thanks for your reply, Kai. That's good news, however iOS and 
Android support is crucial. I hope D can soon be ported to ARM, 
it's just too important.
Nov 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-14 17:21, Chris wrote:


 Thanks for your reply, Kai. That's good news, however iOS and Android
 support is crucial. I hope D can soon be ported to ARM, it's just too
 important.


If you want to do anything useful on iOS you need to use Objective-C 
libraries, for that you bascilly need this:

http://michelf.ca/projects/d-objc/

Latest update, but still quite outdated: 
https://github.com/jacob-carlborg/dmd/tree/d-objc

-- 
/Jacob Carlborg
Nov 14 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 15 November 2013 05:14, Jacob Carlborg <doob me.com> wrote:


 On 2013-11-14 17:21, Chris wrote:

  Thanks for your reply, Kai. That's good news, however iOS and Android

 support is crucial. I hope D can soon be ported to ARM, it's just too
 important.


 If you want to do anything useful on iOS you need to use Objective-C
 libraries, for that you bascilly need this:

 http://michelf.ca/projects/d-objc/

 Latest update, but still quite outdated: https://github.com/jacob-
 carlborg/dmd/tree/d-objc



Very good point. I wonder if there's room to make a push for this in 2.065.
Nov 14 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 00:35, Manu wrote:


 Very good point. I wonder if there's room to make a push for this in 2.065.


Highly  unlikely. It seems like Walter wanted us to first implement ARC, 
to not be worse the Objective-C currently is. But we haven't been able 
to come to an agreement on how to do that.

As Michel noted it currently only supports 32bit and the legacy runtime. 
Although I think it still would be usable to include, even without ARC 
and 64bit/modern runtime. It will just get harder to keep up to date the 
longer time it takes.

http://forum.dlang.org/thread/kq7li9$2j9v$1 digitalmars.com?page=4#post-kqcm79:241eqf:241:40digitalmars.com

http://forum.dlang.org/thread/l34lei$255v$1 digitalmars.com

-- 
/Jacob Carlborg
Nov 14 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-15 07:26:56 +0000, Jacob Carlborg <doob me.com> said:


 On 2013-11-15 00:35, Manu wrote:
 

 Very good point. I wonder if there's room to make a push for this in 2.065.


 
 Highly  unlikely. It seems like Walter wanted us to first implement 
 ARC, to not be worse the Objective-C currently is. But we haven't been 
 able to come to an agreement on how to do that.


Honestly, what I'd do is implement ARC for Objective-C types in the 
compiler without waiting for Walter to decide on anything. There's 
almost nothing to decide when it comes to how D/Objective-C does it: 
you have to do it the same way as clang. And you can't reuse anything 
Walter will come with without much tinkering because Objective-C ARC 
has to manage autoreleased objects. On the other hand once you have 
implemented Objective-C ARC it should be easy to retrofit the mechanics 
of it to other parts of D.

I find it funny how I though about implementing ARC for D/Objective-C 
even before clang came with it. Another idea involved making the D GC 
capable of tracking pointers to external blocks of memory (Objective-C 
objects in this case) and making it call a release function when no 
longer referenced by D code. Some remnants of that:
https://github.com/michelf/druntime/blob/d-objc/src/objc/dobjc.d#L159

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Nov 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 13:42, Michel Fortin wrote:


 Honestly, what I'd do is implement ARC for Objective-C types in the
 compiler without waiting for Walter to decide on anything. There's
 almost nothing to decide when it comes to how D/Objective-C does it: you
 have to do it the same way as clang. And you can't reuse anything Walter
 will come with without much tinkering because Objective-C ARC has to
 manage autoreleased objects. On the other hand once you have implemented
 Objective-C ARC it should be easy to retrofit the mechanics of it to
 other parts of D.


The question is if this is something that Walter would accept to be 
included.

-- 
/Jacob Carlborg
Nov 15 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-15 12:53:18 +0000, Jacob Carlborg <doob me.com> said:


 On 2013-11-15 13:42, Michel Fortin wrote:
 

 Honestly, what I'd do is implement ARC for Objective-C types in the
 compiler without waiting for Walter to decide on anything. There's
 almost nothing to decide when it comes to how D/Objective-C does it: you
 have to do it the same way as clang. And you can't reuse anything Walter
 will come with without much tinkering because Objective-C ARC has to
 manage autoreleased objects. On the other hand once you have implemented
 Objective-C ARC it should be easy to retrofit the mechanics of it to
 other parts of D.


 
 The question is if this is something that Walter would accept to be included.


You mean if Walter would accept D/Objective-C without ARC? No idea. Ask 
him, or submit a pull request just to gauge the reaction.

People have been manually managing memory with 
retain/release/autorelease for more than a decade and it worked pretty 
well, much better than any other manual reference counting scheme out 
there. One problem with introducing ARC later is that you'll need a 
compiler flag to disable or enable ARC to support both legacy and new 
code.

Personally, I'd be more bothered by the lack of 64-bit than the lack of 
ARC, but that might be just because I'm good with 
retain/release/autorelease.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Nov 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 14:38, Michel Fortin wrote:


 You mean if Walter would accept D/Objective-C without ARC? No idea. Ask
 him, or submit a pull request just to gauge the reaction.


No, I was referring to just implementing ARC like it's done in Objective-C.


 People have been manually managing memory with
 retain/release/autorelease for more than a decade and it worked pretty
 well, much better than any other manual reference counting scheme out
 there. One problem with introducing ARC later is that you'll need a
 compiler flag to disable or enable ARC to support both legacy and new code.


That's true.


 Personally, I'd be more bothered by the lack of 64-bit than the lack of
 ARC, but that might be just because I'm good with
 retain/release/autorelease.


Both are important. Although, I personally don't have a need for 64bit, 
but it's nice to have the modern runtime.

-- 
/Jacob Carlborg
Nov 15 2013
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-15 14:02:20 +0000, Jacob Carlborg <doob me.com> said:


 On 2013-11-15 14:38, Michel Fortin wrote:
 

 You mean if Walter would accept D/Objective-C without ARC? No idea. Ask
 him, or submit a pull request just to gauge the reaction.


 
 No, I was referring to just implementing ARC like it's done in Objective-C.


I honestly don't think it can work much differently. You call retain 
and release at the right places. Extending it to other D types is just 
a matter of calling a different functions depending on the type. 
Objective-C has a couple of special cases for pointers to autoreleased 
objects, but that's just a couple more rules to add, and those should 
be kept specific to Objective-C types.

Weak pointers are a more difficult topic, but a separate one I'd say.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Nov 15 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-15 00:35, Manu wrote:


 Very good point. I wonder if there's room to make a push for this in 2.065.


Note, I'm willing work on to syncing my branches to upstream if Walter 
is interested in this. Getting support for 64bit and modern runtime 
would be too far away for this release.

-- 
/Jacob Carlborg
Nov 15 2013
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-14 19:14:03 +0000, Jacob Carlborg <doob me.com> said:


 On 2013-11-14 17:21, Chris wrote:
 

 Thanks for your reply, Kai. That's good news, however iOS and Android
 support is crucial. I hope D can soon be ported to ARM, it's just too
 important.


 
 If you want to do anything useful on iOS you need to use Objective-C 
 libraries, for that you bascilly need this:
 
 http://michelf.ca/projects/d-objc/
 
 Latest update, but still quite outdated: 
 https://github.com/jacob-carlborg/dmd/tree/d-objc


Still no modern runtime support I'd guess? With support only for the 
legacy runtime you're stuck compiling for 32-bit OS X only; 32-bit iOS 
uses the modern runtime.

And since the DMD backend won't emit ARM code, if I were still working 
on this the first thing I'd do is rebase everything to work on top of 
LDC.

Once upon a time, I did port a D game to iOS. I translated it to C++. 
But the amount of Objective-C code was pretty minimal at the end. If I 
had an ARM-capable D compiler at that time, even with no Objective-C 
support, I could have lived happily with D.
http://michelf.ca/projects/tumiki-fighters/

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Nov 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 02:50, Michel Fortin wrote:


 Still no modern runtime support I'd guess? With support only for the
 legacy runtime you're stuck compiling for 32-bit OS X only; 32-bit iOS
 uses the modern runtime.


Right, I forgot about that. I haven't done a single thing on this since 
the last time I announced it.


 And since the DMD backend won't emit ARM code, if I were still working
 on this the first thing I'd do is rebase everything to work on top of LDC.


I think that would be quite difficult. Although it would probably be 
easier to get 64bit and modern runtime support. An advantage of doing it 
in DMD (except that it's already in DMD) is that it's probably a bigger 
chance of it being officially added to D and not just an extension to 
LDD. If it's added to DMD it will automatically be merged by both LDC 
and GDC.

Another idea would be to add it to DMD with the current platform 
support. Then when it's merged with LDC, let them add support for ARM, 
64bit and modern runtime.

BTW, do you automatically scan the newsgroups for 
"http://michelf.ca/projects/d-objc/" :)

-- 
/Jacob Carlborg
Nov 14 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-15 07:33:40 +0000, Jacob Carlborg <doob me.com> said:


 On 2013-11-15 02:50, Michel Fortin wrote:
 

 And since the DMD backend won't emit ARM code, if I were still working
 on this the first thing I'd do is rebase everything to work on top of LDC.


 
 I think that would be quite difficult. Although it would probably be 
 easier to get 64bit and modern runtime support. An advantage of doing 
 it in DMD (except that it's already in DMD) is that it's probably a 
 bigger chance of it being officially added to D and not just an 
 extension to LDD. If it's added to DMD it will automatically be merged 
 by both LDC and GDC.


That was my idea too initially: put it in the reference implementation 
and other implementations will follow, and it'll become part of the 
language. That'd be great. But it's hard when you have to fix the 
backend to emit what you need. I have some fears about that for the 
exception handling stuff in the modern runtime, perhaps they're 
unjustified.



 Another idea would be to add it to DMD with the current platform 
 support. Then when it's merged with LDC, let them add support for ARM, 
 64bit and modern runtime.


I wonder if Walter will approve the merge, despite his stated intention 
to do so eventually. The surface area of that patch is huge, it'll take 
him many hours for an initial review, and probably several iterations 
of that review process will be required to get it to pass. I remember 

(hopefully?) things have changed since then.



 BTW, do you automatically scan the newsgroups for 
 "http://michelf.ca/projects/d-objc/" :)


Haha. No. I skim by topic of interest. But I generally play the passive 
observer. Replying generally brings other replies, begging for more 
followup. I have a couple of replies that were written but which I 
never posted because I anticipated writing the eventual followups 
wouldn't be worth my time. It doesn't help that I tend to spend too 
much time carefully writing anything too, proofreading and weighing 
every word.

But if you're talking about one of my projects there's more chance I'll 
pop in the conversation.


-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Nov 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-11-15 13:41, Michel Fortin wrote:


 That was my idea too initially: put it in the reference implementation
 and other implementations will follow, and it'll become part of the
 language. That'd be great. But it's hard when you have to fix the
 backend to emit what you need. I have some fears about that for the
 exception handling stuff in the modern runtime, perhaps they're
 unjustified.


Yeah, that's the biggest advantage of doing it in LDC. They already have 
the correct back end parts in place.


 I wonder if Walter will approve the merge, despite his stated intention
 to do so eventually. The surface area of that patch is huge, it'll take
 him many hours for an initial review, and probably several iterations of
 that review process will be required to get it to pass. I remember my

 (hopefully?) things have changed since then.


Hopefully things are better now. There seems to be more people now that 
have a greater knowledge of DMD.


 Haha. No. I skim by topic of interest. But I generally play the passive
 observer. Replying generally brings other replies, begging for more
 followup. I have a couple of replies that were written but which I never
 posted because I anticipated writing the eventual followups wouldn't be
 worth my time. It doesn't help that I tend to spend too much time
 carefully writing anything too, proofreading and weighing every word.


Understandable. Like my post about AST macros. It's always a hot topic.


 But if you're talking about one of my projects there's more chance I'll
 pop in the conversation.


-- 
/Jacob Carlborg
Nov 15 2013
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On 11/14/2013 05:14 PM, Kai Nacke wrote:

 But this is only half of the story. My target is Linux/ARM which is
 already supported by druntime/phobos. If you target a smartphone then
 you also have to add Android or iOS support to druntime/phobos.


Currently version (linux) in druntime is equivalent to glibc.
Porting druntime to bionic or newlib might be quite an effort but I have 
no concrete idea what issues to expect.
Nov 14 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 00:18:50 UTC, Martin Nowak wrote:

 On 11/14/2013 05:14 PM, Kai Nacke wrote:

 But this is only half of the story. My target is Linux/ARM 
 which is
 already supported by druntime/phobos. If you target a 
 smartphone then
 you also have to add Android or iOS support to druntime/phobos.


 Currently version (linux) in druntime is equivalent to glibc.
 Porting druntime to bionic or newlib might be quite an effort 
 but I have no concrete idea what issues to expect.


As Kai says, has anyone worked on getting D running on Android 
before?  I've been thinking about attempting an Android port for 
years.  I thought I'd spin up some x86 VMs this weekend and take 
a crack at getting D working on Android/x86 
(http://www.android-x86.org/) as a first step.  If anyone has 
started on this already, I could chip in on their branch.

Also, does dmd have any support for cross-compilation or is it 
better to stick to ldc/gdc when cross compiling to Android?

On a related note, it looks like Rust was ported to Android/ARM 
earlier this year:

https://github.com/mozilla/rust/wiki/Doc-building-for-android
Nov 14 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:

 On Friday, 15 November 2013 at 00:18:50 UTC, Martin Nowak wrote:

 On 11/14/2013 05:14 PM, Kai Nacke wrote:

 But this is only half of the story. My target is Linux/ARM 
 which is
 already supported by druntime/phobos. If you target a 
 smartphone then
 you also have to add Android or iOS support to 
 druntime/phobos.


 Currently version (linux) in druntime is equivalent to glibc.
 Porting druntime to bionic or newlib might be quite an effort 
 but I have no concrete idea what issues to expect.


 As Kai says, has anyone worked on getting D running on Android 
 before?  I've been thinking about attempting an Android port 
 for years.  I thought I'd spin up some x86 VMs this weekend and 
 take a crack at getting D working on Android/x86 
 (http://www.android-x86.org/) as a first step.  If anyone has 
 started on this already, I could chip in on their branch.

 Also, does dmd have any support for cross-compilation or is it 
 better to stick to ldc/gdc when cross compiling to Android?

 On a related note, it looks like Rust was ported to Android/ARM 
 earlier this year:

 https://github.com/mozilla/rust/wiki/Doc-building-for-android


Yes, have a look at an initial port of GDC to Android

https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android
Nov 14 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 07:22:07 UTC, Paulo Pinto wrote:

 On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:

 As Kai says, has anyone worked on getting D running on Android 
 before?  I've been thinking about attempting an Android port 
 for years.  I thought I'd spin up some x86 VMs this weekend 
 and take a crack at getting D working on Android/x86 
 (http://www.android-x86.org/) as a first step.  If anyone has 
 started on this already, I could chip in on their branch.


 Yes, have a look at an initial port of GDC to Android

 https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android


Thanks for the link.  It looks like Johannes Pfau took a stab at 
getting some minimal Android support into gdc a couple years 
back, with the handful of small patches listed here:

https://bitbucket.org/jpf/gdc/branch/android

Anyone get any farther than that?

Would it make sense to use dmd for linux/x86 to cross-compile to 
Android/x86 or is this a job for ldc/gdc only?
Nov 15 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 15 November 2013 at 08:24:55 UTC, Joakim wrote:

 On Friday, 15 November 2013 at 07:22:07 UTC, Paulo Pinto wrote:

 On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:

 As Kai says, has anyone worked on getting D running on 
 Android before?  I've been thinking about attempting an 
 Android port for years.  I thought I'd spin up some x86 VMs 
 this weekend and take a crack at getting D working on 
 Android/x86 (http://www.android-x86.org/) as a first step.  
 If anyone has started on this already, I could chip in on 
 their branch.


 Yes, have a look at an initial port of GDC to Android

 https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android


 Thanks for the link.  It looks like Johannes Pfau took a stab 
 at getting some minimal Android support into gdc a couple years 
 back, with the handful of small patches listed here:

 https://bitbucket.org/jpf/gdc/branch/android

 Anyone get any farther than that?

 Would it make sense to use dmd for linux/x86 to cross-compile 
 to Android/x86 or is this a job for ldc/gdc only?


I would say ldc/gdc only, as LLVM/gcc are the supported NDK 
toolchains and dmd lacks an ARM backend.
Nov 15 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 08:54:21 UTC, Paulo Pinto wrote:

 On Friday, 15 November 2013 at 08:24:55 UTC, Joakim wrote:

 Would it make sense to use dmd for linux/x86 to cross-compile 
 to Android/x86 or is this a job for ldc/gdc only?


 I would say ldc/gdc only, as LLVM/gcc are the supported NDK 
 toolchains and dmd lacks an ARM backend.


Yeah, I'm aware of these facts, but I don't think they matter.  
For one, dmd not having an ARM backend doesn't impact me since 
I'm targeting Android/x86 for now, :) as stated earlier.  I don't 
think it's relevant what toolchains are integrated into the NDK 
as, for example, the Free Pascal compiler can now compile to 
Android and it isn't based on gcc or llvm:

http://wiki.freepascal.org/Android

I think the bigger issue is that llvm/gcc and therefore ldc/gdc 
have support for cross-compilation, but I don't know the status 
of cross-compiling support with dmd.
Nov 15 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:

 On Friday, 15 November 2013 at 08:54:21 UTC, Paulo Pinto wrote:

 On Friday, 15 November 2013 at 08:24:55 UTC, Joakim wrote:

 Would it make sense to use dmd for linux/x86 to cross-compile 
 to Android/x86 or is this a job for ldc/gdc only?


 I would say ldc/gdc only, as LLVM/gcc are the supported NDK 
 toolchains and dmd lacks an ARM backend.


 Yeah, I'm aware of these facts, but I don't think they matter.  
 For one, dmd not having an ARM backend doesn't impact me since 
 I'm targeting Android/x86 for now, :) as stated earlier.  I 
 don't think it's relevant what toolchains are integrated into 
 the NDK as, for example, the Free Pascal compiler can now 
 compile to Android and it isn't based on gcc or llvm:

 http://wiki.freepascal.org/Android

 I think the bigger issue is that llvm/gcc and therefore ldc/gdc 
 have support for cross-compilation, but I don't know the status 
 of cross-compiling support with dmd.


Yes, but FreePascal already had an ARM backend before they 
started with Android, and cross-compiling support infrastructure.

As far as I know dmd does not support cross compiling.

--
Paulo
Nov 15 2013
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 November 2013 09:45, Paulo Pinto <pjmlp progtools.org> wrote:


 On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:


 On Friday, 15 November 2013 at 08:54:21 UTC, Paulo Pinto wrote:


 On Friday, 15 November 2013 at 08:24:55 UTC, Joakim wrote:


 Would it make sense to use dmd for linux/x86 to cross-compile to
 Android/x86 or is this a job for ldc/gdc only?


 I would say ldc/gdc only, as LLVM/gcc are the supported NDK toolchains
 and dmd lacks an ARM backend.


 Yeah, I'm aware of these facts, but I don't think they matter.  For one,
 dmd not having an ARM backend doesn't impact me since I'm targeting
 Android/x86 for now, :) as stated earlier.  I don't think it's relevant
 what toolchains are integrated into the NDK as, for example, the Free
 Pascal compiler can now compile to Android and it isn't based on gcc or
 llvm:

 http://wiki.freepascal.org/Android

 I think the bigger issue is that llvm/gcc and therefore ldc/gdc have
 support for cross-compilation, but I don't know the status of
 cross-compiling support with dmd.


 Yes, but FreePascal already had an ARM backend before they started with
 Android, and cross-compiling support infrastructure.

 As far as I know dmd does not support cross compiling.

 --
 Paulo



-m32/-m64 is the closest you'll get to a cross-compilation in dmd. ;-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 15 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-15 10:45, Paulo Pinto wrote:


 As far as I know dmd does not support cross compiling.


Only for 32bit/64bit on the same architecture.

-- 
/Jacob Carlborg
Nov 15 2013
prev sibling parent reply "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 09:45:42 UTC, Paulo Pinto wrote:

 As far as I know dmd does not support cross compiling.


I started skimming the dmd source to see how it handled porting 
to new platforms and I found the following:

  * Linux Version
  * -------------
  * There are two main issues: hosting the compiler on linux,
  * and generating (targetting) linux executables.
  * The "linux" and "__GNUC__" macros control hosting issues
  * for operating system and compiler dependencies, respectively.
  * To target linux executables, use ELFOBJ for things specific to 
the
  * ELF object file format, and TARGET_LINUX for things specific to
  * the linux memory model.
  * If this is all done right, one could generate a linux object 
file
  * even when compiling on win32, and vice versa.
  * The compiler source code currently uses these macros very 
inconsistently
  * with these goals, and should be fixed.
https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cdef.h#L71

So it appears that the dmd backend has some support for 
cross-compiling, although likely incomplete.
Nov 15 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
Thanks for all your answers. I see that it's still a big big 
issue. I believe we really have to push this, because ARM support 
is vital. If we want people to use D, there will have to be a 
port to ARM, else it will put people off. The code I've been 
working on runs fine on Windows/Mac/Linux. But users will ask for 
effin iPhone or Android support. Everyone wants it and if D can't 
cater for it ...
Nov 15 2013
parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 15 November 2013 at 11:46:29 UTC, Chris wrote:

 I see that it's still a big big issue.


It's not that much effort. Build gdc for ARM and fix druntime.


 I believe we really have to push this, because ARM support is 
 vital.


Well somebody has to do it, so if you have so much interest in 
this...
Nov 15 2013
prev sibling parent "Kai Nacke" <kai redstar.de> writes:
On Friday, 15 November 2013 at 11:18:06 UTC, Joakim wrote:

 On Friday, 15 November 2013 at 09:45:42 UTC, Paulo Pinto wrote:

 As far as I know dmd does not support cross compiling.


 I started skimming the dmd source to see how it handled porting 
 to new platforms and I found the following:

  * Linux Version
  * -------------
  * There are two main issues: hosting the compiler on linux,
  * and generating (targetting) linux executables.
  * The "linux" and "__GNUC__" macros control hosting issues
  * for operating system and compiler dependencies, respectively.
  * To target linux executables, use ELFOBJ for things specific 
 to the
  * ELF object file format, and TARGET_LINUX for things specific 
 to
  * the linux memory model.
  * If this is all done right, one could generate a linux object 
 file
  * even when compiling on win32, and vice versa.
  * The compiler source code currently uses these macros very 
 inconsistently
  * with these goals, and should be fixed.
 https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cdef.h#L71

 So it appears that the dmd backend has some support for 
 cross-compiling, although likely incomplete.


Hi Joakim!

Yes, there is a some support, but not too much. The existence of 
the TARGET_* macros means that you can't have one compiler with 2 
or more platform targets.
But there should be no real problem to create a dmd executable on 
Linux/ARM producing object files for Windows/x86. (Well - no 
problem except for the real data type. :-) ) But who needs that 
kind of cross-compiling?

To be useful for producing ARM binaries, you need an ARM backend. 
This is already available for LDC and GDC. IMHO it is easier to 
pick one of those compilers and think about and create a 
cross-compiling environment instead of starting by zero. (For 

https://github.com/ldc-developers/ldc/issues/490)

Regards,
Kai
Nov 15 2013
prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:

 For one, dmd not having an ARM backend doesn't impact me since 
 I'm targeting Android/x86 for now, :) as stated earlier.


Interesting, then you'll mostly focus on druntime and glibc vs. 
bionic issues.
The linux/ELF support of dmd should mostly work.
Nov 15 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 12:07:19 UTC, Martin Nowak wrote:

 On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:

 For one, dmd not having an ARM backend doesn't impact me since 
 I'm targeting Android/x86 for now, :) as stated earlier.


 Interesting, then you'll mostly focus on druntime and glibc vs. 
 bionic issues.
 The linux/ELF support of dmd should mostly work.


Yes, I thought that would be easier, to split the effort into two 
parts.  First, get D working on Android/x86, then, linux/ARM.  
Some fine day, we combine the two into Android/ARM. :)

On Friday, 15 November 2013 at 12:18:20 UTC, Kai Nacke wrote:

 Hi Joakim!

 Yes, there is a some support, but not too much. The existence 
 of the TARGET_* macros means that you can't have one compiler 
 with 2 or more platform targets.


I think what I'll try initially is to hack the linux target on 
dmd to produce an Android/ELF/x86 executable, by tying into the 
Android NDK and linker.  That might be the shortest path to 
something that works.


 But there should be no real problem to create a dmd executable 
 on Linux/ARM producing object files for Windows/x86. (Well - no 
 problem except for the real data type. :-) ) But who needs that 
 kind of cross-compiling?


Maybe not linux/ARM, but if D ever takes off, I could see it 
being convenient someday to cross-compile Windows/x64 executables 
on linux/x64 servers, perhaps by tying into Wine. I have compiled 
a small Windows utility using dmd under Wine on a FreeBSD host 
before: it worked. :) You wouldn't need to license Windows for a 
bunch of build servers and could cut costs that way.  Obviously 
not a concern today, but we should get cross-compiling working as 
much as possible and cross-compiling to Android might be a good 
first step.  Hell, by then, linux/ARM might be prevalent in the 
data center. ;)


 To be useful for producing ARM binaries, you need an ARM 
 backend. This is already available for LDC and GDC. IMHO it is 
 easier to pick one of those compilers and think about and 
 create a cross-compiling environment instead of starting by 

 https://github.com/ldc-developers/ldc/issues/490)


I'm only focusing on Android/x86 for now: why does everyone keep 
bringing up ARM?  It's almost as though Android/x86 gets 
translated into Android/ARM in their head. ;) Perhaps it is 
easier to cross-compile with ldc/gdc, or perhaps the overall port 
will be harder because I have to then dive into those larger 
llvm/gcc codebases, whereas the dmd backend looks simpler to me, 
at least so far.  I'll give it a whirl with dmd first and then 
move to ldc if I get stuck.

Thanks for the advice, I may end up following it.
Nov 15 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 November 2013 18:40, Joakim <joakim airpost.net> wrote:


 On Friday, 15 November 2013 at 12:07:19 UTC, Martin Nowak wrote:


 On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:


 For one, dmd not having an ARM backend doesn't impact me since I'm
 targeting Android/x86 for now, :) as stated earlier.


 Interesting, then you'll mostly focus on druntime and glibc vs. bionic
 issues.
 The linux/ELF support of dmd should mostly work.


 Yes, I thought that would be easier, to split the effort into two parts.
  First, get D working on Android/x86, then, linux/ARM.  Some fine day, we
 combine the two into Android/ARM. :)


GNU/Linux on ARM will come first... it's now only a matter of time. ;)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 15 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 18:44:20 UTC, Iain Buclaw wrote:

 On 15 November 2013 18:40, Joakim <joakim airpost.net> wrote:

 Yes, I thought that would be easier, to split the effort into 
 two parts.
  First, get D working on Android/x86, then, linux/ARM.  Some 
 fine day, we
 combine the two into Android/ARM. :)


 GNU/Linux on ARM will come first... it's now only a matter of 
 time. ;)


Everything is "only a matter of time." ;) The order is not 
important; it'd be great if linux/ARM is done first, though I 
hope gdc isn't the only one that does it.

On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:

 There are 3 main points which need to be addressed for a solid 
 Android
 port:

 * Druntime must be ported to bionic. Not difficult, but 
 annoying as
   bionic is a mixture between bsd and posix code, so you'll 
 have to
   edit many version statements. All compilers will benefit from 
 that.


Yep, this is the part I'm taking a stab at.


 * You need to implement TLS support. Last time I checked there 
 bionic
   didn't support native TLS and gcc's emulated TLS   doesn't 
 work with
   the D GC.


I think there's TLS support in bionic now, but not with the 
__thread keyword.  I'll look into it more as I go.


 * The main program in Android should always be java code, 
 native code
   loaded as shared libraries. This is implemented in DMD now, 
 but not
   in GDC. (And IIRC not in LDC either?)


I just want to get it working as a pure native compilation option 
for now.  Perhaps someone else will tie D into JNI and get it 
working with Dalvik, I'm not interested in that.

Thanks for the info.
Nov 15 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 15 November 2013 21:14, Joakim <joakim airpost.net> wrote:


 On Friday, 15 November 2013 at 18:44:20 UTC, Iain Buclaw wrote:


 On 15 November 2013 18:40, Joakim <joakim airpost.net> wrote:


 Yes, I thought that would be easier, to split the effort into two parts.
  First, get D working on Android/x86, then, linux/ARM.  Some fine day, we
 combine the two into Android/ARM. :)

  GNU/Linux on ARM will come first... it's now only a matter of time. ;)




 Everything is "only a matter of time." ;) The order is not important; it'd
 be great if linux/ARM is done first, though I hope gdc isn't the only one
 that does it.


 On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:


 There are 3 main points which need to be addressed for a solid Android
 port:

 * Druntime must be ported to bionic. Not difficult, but annoying as
   bionic is a mixture between bsd and posix code, so you'll have to
   edit many version statements. All compilers will benefit from that.


 Yep, this is the part I'm taking a stab at.


  * You need to implement TLS support. Last time I checked there bionic

   didn't support native TLS and gcc's emulated TLS   doesn't work with
   the D GC.


 I think there's TLS support in bionic now, but not with the __thread
 keyword.  I'll look into it more as I go.


  * The main program in Android should always be java code, native code

   loaded as shared libraries. This is implemented in DMD now, but not
   in GDC. (And IIRC not in LDC either?)


 I just want to get it working as a pure native compilation option for now.
  Perhaps someone else will tie D into JNI and get it working with Dalvik,
 I'm not interested in that.


C++ (as in g++) has compiler support with JNI.  I've been turning the idea
in my head as going down this route with D (gdc) support in the same way
through some sort of magic module which generates these special types
(jint, jclass, etc) - not too different from eg: gcc.builtins module.  But
for the time being at least this is a deferred long-term wish list goal.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 15 2013
parent reply "Andrew" <andrew nowhere.com> writes:
A few weeks ago I tried compiling gdc and ldc on my Debian arm 
system and they built Ok but the apps crashed when run. I think 
the error was something to do with fibres in Phobos and druntime.

I tried quickly hacking in missing architecture macros for Arm 
but I didn't know what I was doing so it didn't help.

I'd start with the runtime and Phobos before looking at obj-c 
support and I'll be delighted to test it once you have it working.

There are many more arm Linux systems as well as iOS and Android 
e.g. Raspberry pi's, other SBC's like cubieboard, arduino, 
chromebooks, chromecast, kindle etc. it's estimated that 25% of 
all laptops and 10% of servers will be arm based by the end of 
next year. D will be dead unless it supports arm.

I tried valiantly to get D working and even bought the book but 
alas I've had to abandon it for now.
Nov 16 2013
parent reply Martin Nowak <code dawg.eu> writes:
On 11/16/2013 06:51 PM, Andrew wrote:

 I think the error was something to do with fibres in Phobos and druntime.


Fibers probably won't work out of the box, but they aren't used anywhere 
in druntime/phobos so did you get a hello world to run?
Nov 16 2013
parent reply "Andrew" <andrew nowhere.com> writes:
On Saturday, 16 November 2013 at 18:03:29 UTC, Martin Nowak wrote:

 On 11/16/2013 06:51 PM, Andrew wrote:

 I think the error was something to do with fibres in Phobos 
 and druntime.


 Fibers probably won't work out of the box, but they aren't used 
 anywhere in druntime/phobos so did you get a hello world to run?


Hello world did run but anything that needed to allocate memory 
crashed.
Nov 16 2013
parent reply "Andrew" <andrew nowhere.com> writes:
Just a thought but most ARM systems, Linux based, used EABI 
whereas iOS uses an Apple specific ABI so you'll probably need to 
target each separately. Also there are two variants of EABI 
hard-float (most common now) and soft-float.
Nov 16 2013
parent "Doodoo" <barf barf.com> writes:
  1. Remove the stupid GC, it doesn't scale anyway
  2. Compile to C or C++

DONE!

WAHOOO
Nov 16 2013
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
Bionic even got 
[dl_iterate_phdr](https://github.com/android/platform_bionic/commit/24053a461e7a20f34002
62c1bb122023134989) 
which we need for shared library support.
Write me a mail if you hit any druntime issues during the port.
Nov 15 2013
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 15 Nov 2013 09:24:53 +0100
schrieb "Joakim" <joakim airpost.net>:


 On Friday, 15 November 2013 at 07:22:07 UTC, Paulo Pinto wrote:

 On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:

 As Kai says, has anyone worked on getting D running on Android 
 before?  I've been thinking about attempting an Android port 
 for years.  I thought I'd spin up some x86 VMs this weekend 
 and take a crack at getting D working on Android/x86 
 (http://www.android-x86.org/) as a first step.  If anyone has 
 started on this already, I could chip in on their branch.


 Yes, have a look at an initial port of GDC to Android

 https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android


 
 Thanks for the link.  It looks like Johannes Pfau took a stab at 
 getting some minimal Android support into gdc a couple years 
 back, with the handful of small patches listed here:
 
 https://bitbucket.org/jpf/gdc/branch/android
 
 Anyone get any farther than that?
 
 Would it make sense to use dmd for linux/x86 to cross-compile to 
 Android/x86 or is this a job for ldc/gdc only?


There are 3 main points which need to be addressed for a solid Android
port:

* Druntime must be ported to bionic. Not difficult, but annoying as
  bionic is a mixture between bsd and posix code, so you'll have to
  edit many version statements. All compilers will benefit from that.
* You need to implement TLS support. Last time I checked there bionic
  didn't support native TLS and gcc's emulated TLS   doesn't work with
  the D GC.
* The main program in Android should always be java code, native code
  loaded as shared libraries. This is implemented in DMD now, but not
  in GDC. (And IIRC not in LDC either?)
Nov 15 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:

 * The main program in Android should always be java code, 
 native code
   loaded as shared libraries. This is implemented in DMD now, 
 but not
   in GDC. (And IIRC not in LDC either?)


On the 2.064 frontend branch, LDC already uses the same module 
registration mechanism than DMD, so we are pretty close to 
working shared library support. There are probably two or three 
details that still need attention, but I don't expect any major 
roadblocks. All that is needed at this point is somebody spending 
an evening or two to iron the remaining kinks out.

David
Nov 16 2013
prev sibling parent reply "Elvis Zhou" <elvis.x.zhou gmail.com> writes:
On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:

 On Friday, 15 November 2013 at 00:18:50 UTC, Martin Nowak wrote:

 On 11/14/2013 05:14 PM, Kai Nacke wrote:

 But this is only half of the story. My target is Linux/ARM 
 which is
 already supported by druntime/phobos. If you target a 
 smartphone then
 you also have to add Android or iOS support to 
 druntime/phobos.


 Currently version (linux) in druntime is equivalent to glibc.
 Porting druntime to bionic or newlib might be quite an effort 
 but I have no concrete idea what issues to expect.


 As Kai says, has anyone worked on getting D running on Android 
 before?  I've been thinking about attempting an Android port 
 for years.  I thought I'd spin up some x86 VMs this weekend and 
 take a crack at getting D working on Android/x86 
 (http://www.android-x86.org/) as a first step.  If anyone has 
 started on this already, I could chip in on their branch.

 Also, does dmd have any support for cross-compilation or is it 
 better to stick to ldc/gdc when cross compiling to Android?

 On a related note, it looks like Rust was ported to Android/ARM 
 earlier this year:

 https://github.com/mozilla/rust/wiki/Doc-building-for-android


A month ago I tried to cross compile a Hello World for Android 
with ldc on Debian7 x64 with android_ndk_r9 but failed with lots 
of link errors. One of those issues reveal that qsort is absent 
from Android stdlib, I get over it by grabbing a qsort.c and it 
works. Other issues are beyond my knowledge and I'm too busy to 
continue, hope I can take some time to hack on this late this 
month.
Nov 15 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 10:31:40 UTC, Elvis Zhou wrote:

 On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:

 Also, does dmd have any support for cross-compilation or is it 
 better to stick to ldc/gdc when cross compiling to Android?


 A month ago I tried to cross compile a Hello World for Android 
 with ldc on Debian7 x64 with android_ndk_r9 but failed with 
 lots of link errors. One of those issues reveal that qsort is 
 absent from Android stdlib, I get over it by grabbing a qsort.c 
 and it works. Other issues are beyond my knowledge and I'm too 
 busy to continue, hope I can take some time to hack on this 
 late this month.


What did you modify in ldc to try and get it to work with the NDK 
and compile an Android-compatible binary?

I spent some time setting up the appropriate VMs and looking at 
the relevant Android dev tools myself.  It appears that the 
Android NDK uses a lightly patched version of stock llvm/clang 
3.3, along with the gold linker.  Their patches are available 
online:

https://android.googlesource.com/toolchain/llvm/+log/release_33
https://android.googlesource.com/toolchain/clang/+log/release_33

Their llvm is the same as llvm 3.3 until commit ce33750 and clang 
is the same until commit 20c7d45.  The stock llvm/clang 3.3 have 
some limited support for Android, not much.  I'm going to start 
going through those patches next.

Since there are only about 50-100 llvm/clang patches, many of 
them architecture-specific and so not necessary, this suggests 
that the Android ABI is not that different from linux.  Although, 
when I ran ldd from Arch linux on an x86 sample app compiled by 
the NDK, it said "error while loading shared libraries: 
/usr/lib/libc.so: invalid ELF header," suggesting there is some 
difference.  They wrote their own ldd for the NDK, which works 
fine with their generated code:

https://android.googlesource.com/platform/ndk/+/master/sources/host-tools/ndk-depends/ndk-depends.cc

Turns out I was wrong earlier when I said I'd compile D to pure 
native, as opposed to a shared library pulled in through JNI, as 
the former is not possible on Android.  I saw some docs earlier 
where they said you can write pure native apps now and you can, 
but I now see that you still have to compile it to a shared 
library, because they want everything sandboxed within Dalvik.  
You provide an android_main function as the entry point from 
Dalvik into the native app/library, so shared library support and 
some JNI compatibility are necessary for D to work on Android.

It appears the next steps to get D working on Android/x86 are:

1) Get a basic D "hello world" shared library to compile and run 
on Android, by modifying dmd to generate an Android-compatible 
shared library.
2) Get druntime and phobos working as much as possible.
3) Translate the remaining native Android API headers so they can 
be called from D.

I was hoping to mostly work on 2), but it appears there's some 
work for 1) that has to be done first.  If anybody else wants to 
help with 1), you too can take a look at the above llvm/clang 
commits and let us know what you find.
Nov 22 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Friday, 22 November 2013 at 18:01:44 UTC, Joakim wrote:

 I spent some time setting up the appropriate VMs and looking at 
 the relevant Android dev tools myself.  It appears that the 
 Android NDK uses a lightly patched version of stock llvm/clang 
 3.3, along with the gold linker.  Their patches are available 
 online:

 https://android.googlesource.com/toolchain/llvm/+log/release_33
 https://android.googlesource.com/toolchain/clang/+log/release_33

 Their llvm is the same as llvm 3.3 until commit ce33750 and 
 clang is the same until commit 20c7d45.  The stock llvm/clang 
 3.3 have some limited support for Android, not much.  I'm going 
 to start going through those patches next.

 Since there are only about 50-100 llvm/clang patches, many of 
 them architecture-specific and so not necessary, this suggests 
 that the Android ABI is not that different from linux.


Alright, went through all the Android llvm/clang patches and 
there's little of significance.  They hardcode two clang options 
for android/x86, -mstackrealign and -msse3, add a few tweaks for 
ARM, and that's about it.  Most of the patches are for some other 
NDK work by MediaTek, which don't appear to be used by the 
official Android NDK.

I was able to compile an identical stripped shared library from 
the samples just by using the stock clang 3.3 that's installed in 
Arch linux, once I added the two hardcoded flags in with the rest 
of the flags their makefiles generate, so you really don't even 
need to use their compiler, at least for Android/x86.

Next step, get dmd to do the same with a "hello world" native 
Android app.  I'll update this thread as I go, for anyone who's 
interested.
Nov 25 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 25 November 2013 at 10:38:24 UTC, Joakim wrote:

 On Friday, 22 November 2013 at 18:01:44 UTC, Joakim wrote:

 I spent some time setting up the appropriate VMs and looking 
 at the relevant Android dev tools myself.  It appears that the 
 Android NDK uses a lightly patched version of stock llvm/clang 
 3.3, along with the gold linker.  Their patches are available 
 online:

 https://android.googlesource.com/toolchain/llvm/+log/release_33
 https://android.googlesource.com/toolchain/clang/+log/release_33

 Their llvm is the same as llvm 3.3 until commit ce33750 and 
 clang is the same until commit 20c7d45.  The stock llvm/clang 
 3.3 have some limited support for Android, not much.  I'm 
 going to start going through those patches next.

 Since there are only about 50-100 llvm/clang patches, many of 
 them architecture-specific and so not necessary, this suggests 
 that the Android ABI is not that different from linux.


 Alright, went through all the Android llvm/clang patches and 
 there's little of significance.  They hardcode two clang 
 options for android/x86, -mstackrealign and -msse3, add a few 
 tweaks for ARM, and that's about it.  Most of the patches are 
 for some other NDK work by MediaTek, which don't appear to be 
 used by the official Android NDK.

 I was able to compile an identical stripped shared library from 
 the samples just by using the stock clang 3.3 that's installed 
 in Arch linux, once I added the two hardcoded flags in with the 
 rest of the flags their makefiles generate, so you really don't 
 even need to use their compiler, at least for Android/x86.

 Next step, get dmd to do the same with a "hello world" native 
 Android app.  I'll update this thread as I go, for anyone who's 
 interested.


Thanks, I'm interested.
Nov 25 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Monday, 25 November 2013 at 11:32:56 UTC, Chris wrote:

 On Monday, 25 November 2013 at 10:38:24 UTC, Joakim wrote:

 Next step, get dmd to do the same with a "hello world" native 
 Android app.  I'll update this thread as I go, for anyone 
 who's interested.


 Thanks, I'm interested.


I just spent a couple hours trying to get dmd to compile a "hello 
world" app on linux/x86 without druntime and phobos, so I might 
as well document it here.  After looking at a bunch of old 
newsgroup posts and some druntime source, I came up with the 
following foo.d:

extern (C) void puts(const char*);
extern (C) int main() {puts("Booya cuddie!\n");return 0;}

I compiled foo.d with a local, unpatched build of dmd from git as 
of 10 days ago, dmd compiled by clang++:

./src/dmd -v foo.d -betterC -defaultlib=

No good, it wants an object.d, despite being a better C:

Error: cannot find source code for runtime library file 'object.d'
        dmd might not be correctly installed. Run 'dmd -man' for 
installation instructions.
Specify path to file 'object.d' with -I switch

So I copied object.di from druntime into the same directory, but 
it turns out that simply placing an empty file called object.di 
there also works. :)

Next error, it doesn't link:

foo.o:(.text.d_dso_init[.data.d_dso_rec]+0x33): undefined 
reference to `_d_dso_registry'
collect2: error: ld returned 1 exit status
--- errorlevel 1

So I checked the symbols from the object file it did build:


 nm foo.o


00000000 t
          U _GLOBAL_OFFSET_TABLE_
          U _d_dso_registry
00000000 T main

It turns out that there's a weak reference to _d_dso_registry for 
ELF object files, but it was recently made a requirement on linux 
only.  I got rid of that requirement by changing the 
REQUIRE_DSO_REGISTRY define to this line in 
./src/backend/elfobj.c:

#define REQUIRE_DSO_REGISTRY (DMDV2 && TARGET_RLINUX)

Recompile dmd and foo.d now builds and runs. :) Obviously, this 
patch shouldn't be necessary if you're not on linux.

Next, getting this minimal app running on Android/x86.  It turns 
out there is some support for building executables directly in 
the Android NDK, just undocumented, though the docs are fairly 
bad generally.
Nov 25 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 25 November 2013 at 22:32:26 UTC, Joakim wrote:

 On Monday, 25 November 2013 at 11:32:56 UTC, Chris wrote:

 On Monday, 25 November 2013 at 10:38:24 UTC, Joakim wrote:

 Next step, get dmd to do the same with a "hello world" native 
 Android app.  I'll update this thread as I go, for anyone 
 who's interested.


 Thanks, I'm interested.


 I just spent a couple hours trying to get dmd to compile a 
 "hello world" app on linux/x86 without druntime and phobos, so 
 I might as well document it here.  After looking at a bunch of 
 old newsgroup posts and some druntime source, I came up with 
 the following foo.d:

 extern (C) void puts(const char*);
 extern (C) int main() {puts("Booya cuddie!\n");return 0;}

 I compiled foo.d with a local, unpatched build of dmd from git 
 as of 10 days ago, dmd compiled by clang++:

 ./src/dmd -v foo.d -betterC -defaultlib=

 No good, it wants an object.d, despite being a better C:

 Error: cannot find source code for runtime library file 
 'object.d'
        dmd might not be correctly installed. Run 'dmd -man' for 
 installation instructions.
 Specify path to file 'object.d' with -I switch

 So I copied object.di from druntime into the same directory, 
 but it turns out that simply placing an empty file called 
 object.di there also works. :)

 Next error, it doesn't link:

 foo.o:(.text.d_dso_init[.data.d_dso_rec]+0x33): undefined 
 reference to `_d_dso_registry'
 collect2: error: ld returned 1 exit status
 --- errorlevel 1

 So I checked the symbols from the object file it did build:


 nm foo.o


 00000000 t
          U _GLOBAL_OFFSET_TABLE_
          U _d_dso_registry
 00000000 T main

 It turns out that there's a weak reference to _d_dso_registry 
 for ELF object files, but it was recently made a requirement on 
 linux only.  I got rid of that requirement by changing the 
 REQUIRE_DSO_REGISTRY define to this line in 
 ./src/backend/elfobj.c:

 #define REQUIRE_DSO_REGISTRY (DMDV2 && TARGET_RLINUX)

 Recompile dmd and foo.d now builds and runs. :) Obviously, this 
 patch shouldn't be necessary if you're not on linux.

 Next, getting this minimal app running on Android/x86.  It 
 turns out there is some support for building executables 
 directly in the Android NDK, just undocumented, though the docs 
 are fairly bad generally.


Interesting. Johannes mentioned that the main app should always 
be in Java so it goes through Dalvik. I've done some JNI-D stuff 
already (only a proof-of-concept command line app though). I 
wonder what's the best way of porting D to mobile OS's (mainly 
Android and iOS).
Nov 26 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Tuesday, 26 November 2013 at 09:53:07 UTC, Chris wrote:

 On Monday, 25 November 2013 at 22:32:26 UTC, Joakim wrote:

 Next, getting this minimal app running on Android/x86.  It 
 turns out there is some support for building executables 
 directly in the Android NDK, just undocumented, though the 
 docs are fairly bad generally.




Whoo, I just got the above "hello world" app to run on 
Android/x86 4.3! :D I just compiled the object file with dmd 
patched to take out _d_dso_registry and using the invocation 
above, then linked it with the gold linker, Android libraries, 
and flags that the Android NDK uses, and ran it from a terminal 
in an Android/x86 VM.  I was not looking forward to debugging 
arcane ABI issues and it looks like I may not have to. :) I think 
I'll just use this pure native route to port druntime for now.


 Interesting. Johannes mentioned that the main app should always 
 be in Java so it goes through Dalvik. I've done some JNI-D 
 stuff already (only a proof-of-concept command line app 
 though). I wonder what's the best way of porting D to mobile 
 OS's (mainly Android and iOS).


That is what the docs say if you want to build a native Android 
app, presumably that you distribute through the Play Store.  But 
you can always build a native app for your own local dev build of 
Android, at least for porting purposes.

But look at the test-libstdc++ sample app in the NDK: they 
actually build it as an executable, not a shared library.  I 
haven't tested yet if that's a mistake or if it will actually 
work.  In other words, I don't know if they enforce the shared 
library approach, whether technically or through some Play Store 
certification process, but it certainly is the officially blessed 
approach.

What JNI-D stuff have you tried and on what platform, linux/x86?  
I'll try the shared library approach on Android at some point and 
report back.
Nov 26 2013
next sibling parent reply "Joakim" <joakim airpost.net> writes:
On Tuesday, 26 November 2013 at 11:22:59 UTC, Joakim wrote:

 That is what the docs say if you want to build a native Android 
 app, presumably that you distribute through the Play Store.  
 But you can always build a native app for your own local dev 
 build of Android, at least for porting purposes.


Sorry, that should be "native executable" in the second instance, 
ie it doesn't have to be a shared library if you're just 
deploying it locally.
Nov 26 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 26 Nov 2013 12:36:19 +0100
schrieb "Joakim" <joakim airpost.net>:


 On Tuesday, 26 November 2013 at 11:22:59 UTC, Joakim wrote:

 That is what the docs say if you want to build a native Android 
 app, presumably that you distribute through the Play Store.  
 But you can always build a native app for your own local dev 
 build of Android, at least for porting purposes.


 Sorry, that should be "native executable" in the second instance, 
 ie it doesn't have to be a shared library if you're just 
 deploying it locally.


Native apps are working, just not officially supported. I actually had
a native Hello World working on ARM/Android with GDC, however fixing
bugs related to native apps usually isn't high priority on Android.

This bug for example wasn't fixed back then and was a showstopper:
http://code.google.com/p/android/issues/detail?id=28598

Last time I looked pure native apps couldn't use the GUI though, has
that changed?
Nov 26 2013
parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 26 November 2013 at 17:12:38 UTC, Johannes Pfau wrote:

 Native apps are working, just not officially supported. I 
 actually had
 a native Hello World working on ARM/Android with GDC, however 
 fixing
 bugs related to native apps usually isn't high priority on 
 Android.

 This bug for example wasn't fixed back then and was a 
 showstopper:
 http://code.google.com/p/android/issues/detail?id=28598


I don't see how that was a showstopper when you could avoid it 
simply by using the right flags, as noted in the penultimate 
comment there.  Also, I get the impression that the build system 
makefiles for Android itself are pretty much the same as the NDK, 
so Android would have some pretty serious problems if they didn't 
get their toolchain for building native system, ie non-java, 
processes working right. ;)


 Last time I looked pure native apps couldn't use the GUI 
 though, has
 that changed?


Depends what you mean.  The NDK has always been pitched at game 
devs, so you can't call the Android UI components directly from 
native code AFAIK.  But you could use OpenGL ES 2.0 from Android 
2.0 and employ EGL with a pure native shared library app since 
Android 2.3 in 2010, so you could employ your own OpenGL-based 
GUI toolkit for a long time:

http://mobilepearls.com/labs/native-android-api/ndk/docs/STABLE-APIS.html

And you could always use JNI to do your GUI in java and 
number-crunching in C/C++, but yeah, that's not pure native.
Nov 26 2013
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 26 November 2013 at 11:22:59 UTC, Joakim wrote:

 What JNI-D stuff have you tried and on what platform, 
 linux/x86?  I'll try the shared library approach on Android at 
 some point and report back.


If I remember correctly, I did something like this (think it was 
on OS X):

1. Create D library (seems to be necessary?)
dmd -lib hello.d -oflibhelloD

2. Compile (do not link)
gcc -c hello.c -o helloC.o // Calls D code

3. JNI (compile)
gcc -c -I/path/to/Java/Headers Test.c -o Test.o // JNI file 
(calls hello.c)

4. Create library.
gcc -dynamiclib -o libTest.jnilib -lphobos2 -lhelloD Test.o 
helloC.o

And it worked. I don't know, if step 2. is necessary at all.

I've also been able to successfully combine Python and D, so that 
the D module could be loaded and used by Python like any other 
module. I could also link D and Objective-C. But that was all on 
Desktop (Mac OS X and Linux). I haven't tried it for Android or 
iOS yet.
Nov 27 2013
next sibling parent reply "Joakim" <joakim airpost.net> writes:
On Wednesday, 27 November 2013 at 13:52:17 UTC, Chris wrote:

 On Tuesday, 26 November 2013 at 11:22:59 UTC, Joakim wrote:

 What JNI-D stuff have you tried and on what platform, 
 linux/x86?  I'll try the shared library approach on Android at 
 some point and report back.


 If I remember correctly, I did something like this (think it 
 was on OS X):

 1. Create D library (seems to be necessary?)
 dmd -lib hello.d -oflibhelloD

 2. Compile (do not link)
 gcc -c hello.c -o helloC.o // Calls D code

 3. JNI (compile)
 gcc -c -I/path/to/Java/Headers Test.c -o Test.o // JNI file 
 (calls hello.c)

 4. Create library.
 gcc -dynamiclib -o libTest.jnilib -lphobos2 -lhelloD Test.o 
 helloC.o

 And it worked. I don't know, if step 2. is necessary at all.

 I've also been able to successfully combine Python and D, so 
 that the D module could be loaded and used by Python like any 
 other module. I could also link D and Objective-C. But that was 
 all on Desktop (Mac OS X and Linux). I haven't tried it for 
 Android or iOS yet.


Hmm, that seems pretty convoluted, hopefully it won't be as bad 
on Android.

I've started porting core.stdc from druntime to Android, so far, 
so good.  One oddity I've run into is that stderr doesn't work 
properly on half of the existing OS platforms.  Take this test 
file:
//test.d
import core.stdc.stdio;

extern (C) int main() { fputs("doing this for real?", stderr); 
return 0;}

It doesn't link on Win32, Win64, or Android.  It works on linux 
and FreeBSD.  Here's the output on platforms where it doesn't 
work:

Win 7 x64 with dmd 2.064.2:
C:\dmd2>.\windows\bin\dmd.exe -m32 test.d
OPTLINK (R) for Win32  Release 8.00.13
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
test.obj(test)
  Error 42: Symbol Undefined _stderr
--- errorlevel 1

C:\dmd2>.\windows\bin\dmd.exe -m64 test.d
test.obj : error LNK2019: unresolved external symbol stderr 
referenced in functi
on main
test.exe : fatal error LNK1120: 1 unresolved externals
--- errorlevel 1120

Arch linux x86 compiling for Android x86:

test.o:test.d:function main: error: undefined reference to 
'stderr'

The linker seems to find the symbol for stderr on platforms where 
it's defined extern in libc.  On platforms like Android, with the 
following stdio.h and stdio.d, not so much.

Android:
stdio.h:
__BEGIN_DECLS
extern FILE __sF[];
__END_DECLS
--snip--
#define stdin   (&__sF[0])
#define stdout  (&__sF[1])
#define stderr  (&__sF[2])
https://android.googlesource.com/platform/bionic/+/master/libc/include/stdio.h

My stdio.d:

else version( Android )
{
     enum
     {
         _IOFBF = 0,
         _IOLBF = 1,
         _IONBF = 2,
     }

     private extern shared FILE[3] __sF;

         shared stdin  = &__sF[0];
         shared stdout = &__sF[1];
         shared stderr = &__sF[2];
}

I followed the example of Solaris and Win32, but it appears those 
don't work either.  My guess is that OS X will work and Solaris 
won't, based on these similarities, but I don't have either 
accessible to test on.  If I call &__sF[2] directly from test.d, 
that does work on Android.

So the question is, when one has a #define macro like the above, 
how does one create the equivalent symbol in D?  It appears that 
the authors of druntime are unsure of how to do this also.
Dec 01 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01.12.2013 14:30, Joakim wrote:

 //test.d
 import core.stdc.stdio;

 extern (C) int main() { fputs("doing this for real?", stderr); return 0;}

 It doesn't link on Win32, Win64, or Android.  It works on linux and
 FreeBSD.  Here's the output on platforms where it doesn't work:


The reason this does not work on Win32/Win64 comes from declaring main 
as "extern(C)", which declares "main" for the C runtime. This prevents 
adding an implicite include directive to add the phobos library to the 
link. This happens only for D's main.

So, you should either drop the "extern(C)" or add phobos.lib to the 
command line.

If including the library is not an option, you'll have to repeat the 
respective declarations in your source. Just adding core.stdc.stdio to 
the command line might also work.
Dec 02 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Monday, 2 December 2013 at 08:25:39 UTC, Rainer Schuetze wrote:

 On 01.12.2013 14:30, Joakim wrote:

 //test.d
 import core.stdc.stdio;

 extern (C) int main() { fputs("doing this for real?", stderr); 
 return 0;}

 It doesn't link on Win32, Win64, or Android.  It works on 
 linux and
 FreeBSD.  Here's the output on platforms where it doesn't work:


 The reason this does not work on Win32/Win64 comes from 
 declaring main as "extern(C)", which declares "main" for the C 
 runtime. This prevents adding an implicite include directive to 
 add the phobos library to the link. This happens only for D's 
 main.


I just tested this: you're right, removing the "extern (C)" 
linkage for main fixes the linking problem on Win32/Win64.  That 
makes sense that druntime/phobos wasn't added to the link, as the 
symbols _were_ added by the above stdio.d for Android.

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.


 So, you should either drop the "extern(C)" or add phobos.lib to 
 the command line.


Yes, both do fix the problem.


 If including the library is not an option, you'll have to 
 repeat the respective declarations in your source. Just adding 
 core.stdc.stdio to the command line might also work.


I was reusing the existing Makefiles as much as possible and 
archiving the ported core.stdc druntime object files for Android 
into a libphobos2.a, as that library name is hardcoded into dmd.  
Perhaps that was a mistake, I'll look further into why it doesn't 
link.
Dec 02 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 02.12.2013 10:36, Joakim wrote:

 On Monday, 2 December 2013 at 08:25:39 UTC, Rainer Schuetze wrote:

 On 01.12.2013 14:30, Joakim wrote:

 //test.d
 import core.stdc.stdio;

 extern (C) int main() { fputs("doing this for real?", stderr); return
 0;}

 It doesn't link on Win32, Win64, or Android.  It works on linux and
 FreeBSD.  Here's the output on platforms where it doesn't work:


 The reason this does not work on Win32/Win64 comes from declaring main
 as "extern(C)", which declares "main" for the C runtime. This prevents
 adding an implicite include directive to add the phobos library to the
 link. This happens only for D's main.


 I just tested this: you're right, removing the "extern (C)" linkage for
 main fixes the linking problem on Win32/Win64.  That makes sense that
 druntime/phobos wasn't added to the link, as the symbols _were_ added by
 the above stdio.d for Android.

 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.


 So, you should either drop the "extern(C)" or add phobos.lib to the
 command line.


 Yes, both do fix the problem.


 If including the library is not an option, you'll have to repeat the
 respective declarations in your source. Just adding core.stdc.stdio to
 the command line might also work.


 I was reusing the existing Makefiles as much as possible and archiving
 the ported core.stdc druntime object files for Android into a
 libphobos2.a, as that library name is hardcoded into dmd. Perhaps that
 was a mistake, I'll look further into why it doesn't link.


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?

You can change the name of the runtime library with -defaultlib.
Dec 02 2013
parent reply "Joakim" <joakim airpost.net> writes:
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.
Dec 15 2013
parent reply "Joakim" <joakim airpost.net> writes:
 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.
Dec 28 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Dec 29 2013
prev sibling parent reply "Joakim" <joakim airpost.net> writes:
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. ;)
Mar 21 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
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.
Apr 23 2014
parent Jacob Carlborg <doob me.com> writes:
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
Apr 23 2014
prev sibling parent "Joakim" <joakim airpost.net> writes:
Alright, submitted my first pull request for Android support in 
druntime:

https://github.com/D-Programming-Language/druntime/pull/681

I'll push all further changes to druntime in my android branch:

https://github.com/joakim-noah/druntime/tree/android

Hopefully, I can get some subset of D working on Android/x86 over 
the next couple weeks. :)
Dec 01 2013
prev sibling next sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
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...
Dec 13 2013
parent reply "Joakim" <joakim airpost.net> writes:
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.
Dec 13 2013
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Dec 13, 2013 8:40 PM, "Joakim" <joakim airpost.net> wrote:

 On Friday, 13 December 2013 at 17:18:30 UTC, Lu=EDs 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-rum=
or

 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/6803132b0d76ef895=
718fe8f0e835bf8dc3d0ecf#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=3Dnews_item&px=3DMTQ1ODM

 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
--=20
Iain Buclaw

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



 Dec 14 2013



prev sibling  parent  "Dejan Lekic" <dejan.lekic gmail.com>  writes:


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! ;)



 Apr 23 2014