www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D on ARM

reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
So it seems that ARM is going to be getting quite a bit bigger in the
future, between the rise of smarter phones and Windows 8 support, and in
general D just doesn't exist on ARM.
GDC kind of works, but I've been unable to come up with a simple test case
for a bug with the section-anchors optimization, and fibers simply don't
work (although that may be due to some bad alignment in the D versions of
some C data structures that I haven't looked too far into yet).

Aside from that, D is pretty much x86 specific. LDC builds on ARM but
segfaults when trying to build DRuntime, and DMD only supports x86 codegen.
All assembly in DRuntime is x86 specific.

I realize I'm a lurker around here, and while I've tried to get GDC working
a bit better on ARM, I've been mostly unsuccessful, but should we, as a
community, be making some sort of commitment to make this better? I'm not
trying to be imposing (well, I am to some extent, but I realize I have no
right to), but this seems like it will probably get much more important in
the next few years.
Jun 23 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrew Wiley" <wiley.andrew.j gmail.com> wrote in message 
news:mailman.1177.1308888314.14074.digitalmars-d puremagic.com...

 So it seems that ARM is going to be getting quite a bit bigger in the
 future, between the rise of smarter phones and Windows 8 support, and in
 general D just doesn't exist on ARM.
 GDC kind of works, but I've been unable to come up with a simple test case
 for a bug with the section-anchors optimization, and fibers simply don't
 work (although that may be due to some bad alignment in the D versions of
 some C data structures that I haven't looked too far into yet).

 Aside from that, D is pretty much x86 specific. LDC builds on ARM but
 segfaults when trying to build DRuntime, and DMD only supports x86 
 codegen.
 All assembly in DRuntime is x86 specific.

 I realize I'm a lurker around here, and while I've tried to get GDC 
 working
 a bit better on ARM, I've been mostly unsuccessful, but should we, as a
 community, be making some sort of commitment to make this better? I'm not
 trying to be imposing (well, I am to some extent, but I realize I have no
 right to), but this seems like it will probably get much more important in
 the next few years.


Actually, I strongly agree with you. The idea of being able to use something 
better than C/C++ on ARM-level embedded devices is one of the major things 
that drew me to D in the first place, getting close to ten years ago now (I 
was doing some GBA homebrew at the time, and had to use C - it got the job 
done, but it was an anachronistic language even back then). It's kind of 
frustrating that we're still not really there yet (although I admit it's 
been years since I've really had a chance to do anything outside the 
desktop/server). And it's not just getting the basics working, but also 
being able to easily handle embedded-oriented concerns like being able to 
ban GC allocs at compiletime (GC would be inappropriate on something like 
the GBA/DS, for instance). I've always been *far* more interested in 
ARM/embedded issues than the x64/multicore/concurrency issues that have been 
getting most of the focus. So that's been frustrating for me to watch.

Unfortunately, I'm not sure there's much I would personally be able to 
contribute to the cause :/ I know next-to-nothing about compiler backends, 
druntime, LLVM or GCC, and my ARM experience was years ago and was C-only 
without really delving into the asm (neither arm nor thumb).
Jun 23 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/23/2011 9:04 PM, Andrew Wiley wrote:

 So it seems that ARM is going to be getting quite a bit bigger in the future,
 between the rise of smarter phones and Windows 8 support,


I think you're right.

I'd like to get D on the ARM, but it awaits someone willing to do the work.
Jun 24 2011
parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Fri, Jun 24, 2011 at 12:14 PM, Walter Bright
<newshound2 digitalmars.com>wrote:


 On 6/23/2011 9:04 PM, Andrew Wiley wrote:


 So it seems that ARM is going to be getting quite a bit bigger in the
 future,
 between the rise of smarter phones and Windows 8 support,


 I think you're right.

 I'd like to get D on the ARM, but it awaits someone willing to do the work.


Well, my question would be what to aim for.
As I see it, the simplest immediate path is to get GDC working better,
because most/all of the platform-specific ASM in DRuntime is replaced by GCC
intrinsics, which are already available on ARM. Beyond there, we'd need
DRuntime support, which is a good bit larger, and we could probably get LDC
working as well at that point. If we want to go a (very large) step farther,
ARM could be added to the DMD codegen.
One thing I don't know at all is what getting support for Windows/ARM would
look like. What with the object file problems we already have in x86/64, it
seems like ARM would be much harder because there are no legacy linkers
there, just what Microsoft is cooking up. In that regard, getting GDC
working better is probably a good idea because MinGW GCC will probably add
Windows/ARM as a target, which would get us most of the way there.

The good news is that this progression is fairly linear, but the question is
how much we want to aim for and what sort of timeline we want to aim on. In
the meantime, I'll be stepping up my efforts on ARM/GDC and trying to get
the GDC running against the DMD testsuite there so we have a more solid idea
of what's working and what isn't (assuming Iain hasn't beaten me to it, but
I think he's been busy enough between 2.053, 64 bit, Win64, and GCC 4.6).

Nick: I actually have a pretty similar reason for first getting into D,
except that I've been trying to target ARM SoC's, first with a Cirrus Labs
EDB9302, then with a Marvell Sheevaplug running on a Feroceon, then with a
Beagleboard. The change that I see coming is that ARM is moving from
embedded to mainstream, so the level of support necessary needs to adjust to
match.
Jun 24 2011
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Andrew Wiley (wiley.andrew.j gmail.com)'s article

 --00163691fe61ca432504a67a5605
 Content-Type: text/plain; charset=ISO-8859-1
 On Fri, Jun 24, 2011 at 12:14 PM, Walter Bright
 <newshound2 digitalmars.com>wrote:

 On 6/23/2011 9:04 PM, Andrew Wiley wrote:


 So it seems that ARM is going to be getting quite a bit bigger in the
 future,
 between the rise of smarter phones and Windows 8 support,


 I think you're right.

 I'd like to get D on the ARM, but it awaits someone willing to do the work.


 Well, my question would be what to aim for.
 As I see it, the simplest immediate path is to get GDC working better,
 because most/all of the platform-specific ASM in DRuntime is replaced by GCC
 intrinsics, which are already available on ARM. Beyond there, we'd need
 DRuntime support, which is a good bit larger, and we could probably get LDC
 working as well at that point. If we want to go a (very large) step farther,
 ARM could be added to the DMD codegen.
 One thing I don't know at all is what getting support for Windows/ARM would
 look like. What with the object file problems we already have in x86/64, it
 seems like ARM would be much harder because there are no legacy linkers
 there, just what Microsoft is cooking up. In that regard, getting GDC
 working better is probably a good idea because MinGW GCC will probably add
 Windows/ARM as a target, which would get us most of the way there.
 The good news is that this progression is fairly linear, but the question is
 how much we want to aim for and what sort of timeline we want to aim on. In
 the meantime, I'll be stepping up my efforts on ARM/GDC and trying to get
 the GDC running against the DMD testsuite there so we have a more solid idea
 of what's working and what isn't (assuming Iain hasn't beaten me to it, but
 I think he's been busy enough between 2.053, 64 bit, Win64, and GCC 4.6).
 Nick: I actually have a pretty similar reason for first getting into D,
 except that I've been trying to target ARM SoC's, first with a Cirrus Labs
 EDB9302, then with a Marvell Sheevaplug running on a Feroceon, then with a
 Beagleboard. The change that I see coming is that ARM is moving from
 embedded to mainstream, so the level of support necessary needs to adjust to
 match.
 --00163691fe61ca432504a67a5605
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 <div class=3D"gmail_quote">On Fri, Jun 24, 2011 at 12:14 PM, Walter Bright =
 <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshou=
 nd2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
 te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
 ">
 <div class=3D"im">On 6/23/2011 9:04 PM, Andrew Wiley wrote:<br>
 <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
 x #ccc solid;padding-left:1ex">
 So it seems that ARM is going to be getting quite a bit bigger in the futur=
 e,<br>
 between the rise of smarter phones and Windows 8 support,<br>
 </blockquote>
 <br></div>

 <br>

 ork.<br>
 </blockquote></div><br>Well, my question would be what to aim for.<br>As I =
 see it, the simplest immediate path is to get GDC working better, because m=
 ost/all of the platform-specific ASM in DRuntime is replaced by GCC intrins=

 me support, which is a good bit larger, and we could probably get LDC worki=
 ng as well at that point. If we want to go a (very large) step farther, ARM=
  could be added to the DMD codegen.<br>

 ould look like. What with the object file problems we already have in x86/6=
 4, it seems like ARM would be much harder because there are no legacy linke=
 rs there, just what Microsoft is cooking up. In that regard, getting GDC wo=
 rking better is probably a good idea because MinGW GCC will probably add Wi=
 ndows/ARM as a target, which would get us most of the way there.<br>
 <br>The good news is that this progression is fairly linear, but the questi=
 on is how much we want to aim for and what sort of timeline we want to aim =

 ng to get the GDC running against the DMD testsuite there so we have a more=


 4 bit, Win64, and GCC 4.6).<br>
 <br>Nick: I actually have a pretty similar reason for first getting into D,=

 rus Labs EDB9302, then with a Marvell Sheevaplug running on a Feroceon, the=
 n with a Beagleboard. The change that I see coming is that ARM is moving fr=
 om embedded to mainstream, so the level of support necessary needs to adjus=
 t to match.<br>
 --00163691fe61ca432504a67a5605--


I'm actually currently working out a clean reimplementation and design of D2
closures and delegates for D1/D2 - one that means can remove a good quarter of
the
bespoke patches applied to GCC for all supported versions (just to show that I'm
still thinking forward with merging the GDC project in with GCC here) and along
the way, hopefully that will fix some of the more intricate cases in the
testsuite
that we currently fail on - ie: in relation to deeply nested functions inside
nested classes and so forth.


Though I have an ARM board setup for development, it's currently bikeshedded for
future use. Too busy with real programming work, followed by weekend rehearsals
and relations to get the time to boot up the device and start sorting things
out.


Regards
Jun 24 2011
prev sibling parent Patrick Down <patrick.down gmail.com> writes:
Andrew Wiley Wrote:


 So it seems that ARM is going to be getting quite a bit bigger in the
 future, between the rise of smarter phones and Windows 8 support, and in
 general D just doesn't exist on ARM.


I second this.  I've followed D for a while but most of my development has
moved to mobile ARM platforms.
Jun 24 2011