www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D on ARM

reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
--001636c5c18c7a1f3c04a66d4e2d
Content-Type: text/plain; charset=ISO-8859-1

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.

--001636c5c18c7a1f3c04a66d4e2d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

<br></div><div>Aside from that, D is pretty much x86 specific. LDC builds o=
n ARM but segfaults when trying to build DRuntime, and DMD only supports x8=
6 codegen. All assembly in DRuntime is x86 specific.</div><div><br></div>

<div>I realize I&#39;m a lurker around here, and while I&#39;ve tried to ge=
t GDC working a bit better on ARM, I&#39;ve been mostly unsuccessful, but s=
hould we, as a community, be making some sort of commitment to make this be=
tter? I&#39;m not trying to be imposing (well, I am to some extent, but I r=
ealize I have no right to), but this seems like it will probably get much m=
ore important in the next few years.</div>

</div>

--001636c5c18c7a1f3c04a66d4e2d--
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 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.

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> I think you&#39;re right.<br> <br> I&#39;d like to get D on the ARM, but it awaits someone willing to do the w= 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= ics, which are already available on ARM. Beyond there, we&#39;d need DRunti= 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> One thing I don&#39;t know at all is what getting support for Windows/ARM w= 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 = on. In the meantime, I&#39;ll be stepping up my efforts on ARM/GDC and tryi= ng to get the GDC running against the DMD testsuite there so we have a more= solid idea of what&#39;s working and what isn&#39;t (assuming Iain hasn&#3= 9;t beaten me to it, but I think he&#39;s been busy enough between 2.053, 6= 4 bit, Win64, and GCC 4.6).<br> <br>Nick: I actually have a pretty similar reason for first getting into D,= except that I&#39;ve been trying to target ARM SoC&#39;s, first with a Cir= 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 next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--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> I think you&#39;re right.<br> <br> I&#39;d like to get D on the ARM, but it awaits someone willing to do the w= 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= ics, which are already available on ARM. Beyond there, we&#39;d need DRunti= 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> One thing I don&#39;t know at all is what getting support for Windows/ARM w= 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 = on. In the meantime, I&#39;ll be stepping up my efforts on ARM/GDC and tryi= ng to get the GDC running against the DMD testsuite there so we have a more= solid idea of what&#39;s working and what isn&#39;t (assuming Iain hasn&#3= 9;t beaten me to it, but I think he&#39;s been busy enough between 2.053, 6= 4 bit, Win64, and GCC 4.6).<br> <br>Nick: I actually have a pretty similar reason for first getting into D,= except that I&#39;ve been trying to target ARM SoC&#39;s, first with a Cir= 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--
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