D on ARM

[Iain Buclaw]

== Quote from Andrew Wiley (wiley.andrew.j at 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 at 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"><<a href=3D"mailto:newshound2 at digitalmars.com">newshou=
> nd2 at digitalmars.com</a>></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're right.<br>
> <br>
> I'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'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'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'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's working and what isn't (assuming Iain hasn&#3=
> 9;t beaten me to it, but I think he'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've been trying to target ARM SoC'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