www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ARM support

reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Hello,

I'm developing embedded system product on ARM9/Linux platform and I wish 
I could use D and vibe.d for this task.

I have couple of questions in this matter:
- What is the current status of ARM support?
- Does GDC support cross-compiling to ARM?
- Is it possible to remote-debug D code on ARM? (I've used GDB for C++ 
remote debugging on ARM11, I think this should also work with GDC 
compiled code)
- Does druntime support ARM plaforms?
- Does phobos support ARM plaforms?
- Does GC run reliably on ARM (or is it platform independent)?
- Can you estimate eventual cost of supporting D on ARM (think of paid 
bounty).

Thanks for any help.
Jan 09 2014
next sibling parent "Mike" <none none.com> writes:
On Thursday, 9 January 2014 at 18:07:16 UTC, Piotr Szturmaj wrote:
 Hello,

 I'm developing embedded system product on ARM9/Linux platform 
 and I wish I could use D and vibe.d for this task.

I'm new to D, so please take my comments below with that in mind. I'm not really qualified to answer these questions, but I offer my perceptions anyway. I'm working on a bare-metal ARM Cortex-M port, which I believe is quite different from what you are looking for. What exactly is your hardware? RaspberryPi? BeagleBone? Android Tablet?
 I have couple of questions in this matter:
 - What is the current status of ARM support?

I'm not really qualified to answer this question, but the D runtime has a few instances of "version(ARM)" in it, so it appears progress is being made. In my limited experience with the D runtime, it appears that it is mostly dependent on the operating system and the C standard library than the underlying processor. Since Linux support is solid, I'd bet it's not too far away. Just needs someone to pick up the torch and carry it the extra distance. LDC is trying to make some progress with exception handling (http://forum.dlang.org/post/mailman.186.1389078727.15871.digitalmars-d-ldc puremagic.com). I haven't gotten far enough to play with exception handling in GDC, but there's an interesting discussion going on here (http://forum.dlang.org/post/zpvivgzkpxvjlqiwucel forum.dlang.org)
 - Does GDC support cross-compiling to ARM?

Yep. Good documentation here (https://bitbucket.org/timosi/minlibd/wiki/gdc_cross_compiler). More documentation here (http://wiki.dlang.org/GDC/Cross_Compiler). I had some trouble with it, but eventually succeeded. Discussion here (http://forum.dlang.org/post/l6t224$25j2$1 digitalmars.com)
 - Is it possible to remote-debug D code on ARM? (I've used GDB 
 for C++ remote debugging on ARM11, I think this should also 
 work with GDC compiled code)

I use OpenOCD and GDB with a JTAG emulator, and at least the few features I've used work. Exciting GDB developments here (http://forum.dlang.org/post/wnipdgpohgjgmojokssy forum.dlang.org)
 - Does druntime support ARM plaforms?

Not really qualified to answer this, but see my comment above.
 - Does phobos support ARM plaforms?

Again, not qualified to answer this, but I don't believe there's much dependency on the underlying hardware, just the OS and the D runtime.
 - Does GC run reliably on ARM (or is it platform independent)?

New to D, so not qualified to answer, but I'm guessing with OS support, the underlying hardware is not so relevant. I think, however, the type of application you build will have an impact on (perceived) performance with the garbage collector, so programming technique is more important than the GC, IMO.
 - Can you estimate eventual cost of supporting D on ARM (think 
 of paid bounty).

For me, $40,000....OK. I'll take $30,000.
 Thanks for any help.

Sorry if I didn't really provide any.
Jan 09 2014
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Thursday, 9 January 2014 at 18:07:16 UTC, Piotr Szturmaj wrote:
 Hello,

 I'm developing embedded system product on ARM9/Linux platform 
 and I wish I could use D and vibe.d for this task.

 I have couple of questions in this matter:

not a core developer, but I'll take a shot at answering your questions.
 - What is the current status of ARM support?

while the LDC and GDC compilers are trying to utilize the ARM backends of llvm and gcc to add ARM support, as Mike points out, but they're not finished. Not sure where ARM9 specifically fits into all this.
 - Does GDC support cross-compiling to ARM?

 - Is it possible to remote-debug D code on ARM? (I've used GDB 
 for C++ remote debugging on ARM11, I think this should also 
 work with GDC compiled code)

Android/x86, but I have not done so.
 - Does druntime support ARM plaforms?

of x86 assembly, but I have not yet looked into how much of that is optimization and therefore not strictly necessary to reimplement on ARM.
 - Does phobos support ARM plaforms?

still supports x86 best in the cases where it isn't.
 - Does GC run reliably on ARM (or is it platform independent)?

to make it work. The source appears to be fairly independent, but other core features like threading or fibers appear not be.
 - Can you estimate eventual cost of supporting D on ARM (think 
 of paid bounty).

Jan 10 2014
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 10 January 2014 at 08:27:39 UTC, Joakim wrote:
 On Thursday, 9 January 2014 at 18:07:16 UTC, Piotr Szturmaj 
 wrote:
 - Does druntime support ARM plaforms?

amount of x86 assembly, but I have not yet looked into how much of that is optimization and therefore not strictly necessary to reimplement on ARM.

support, mostly just translating arch-dependent headers, in druntime.
Jan 10 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
There were people trying vibe.d on ARM/Linux here and there with 
several issues that may or may not be already fixed by 
LDC/GDC/vibe.d developers. One thread I have found:

http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/6048/

As far as I know it works in general but using any more complex 
projects like vibe.d is likely to trigger any hiding  issues in 
GDC/LDC so one needs to be ready to push through it for greater 
good.
Jan 10 2014
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 10 Jan 2014 08:27:37 +0000
schrieb "Joakim" <joakim airpost.net>:

 On Thursday, 9 January 2014 at 18:07:16 UTC, Piotr Szturmaj wrote:
 Hello,

 I'm developing embedded system product on ARM9/Linux platform 
 and I wish I could use D and vibe.d for this task.

 I have couple of questions in this matter:

not a core developer, but I'll take a shot at answering your questions.
 - What is the current status of ARM support?

while the LDC and GDC compilers are trying to utilize the ARM backends of llvm and gcc to add ARM support, as Mike points out, but they're not finished. Not sure where ARM9 specifically fits into all this.

The exact ARM architecture version doesn't matter that much. I mainly test ARMv5 and ARMv6 older versions are untested. But OS support does matter, I only work on Linux/GLIBC systems right now.
 - Does druntime support ARM plaforms?

of x86 assembly, but I have not yet looked into how much of that is optimization and therefore not strictly necessary to reimplement on ARM.

You'll have to look at GDC/LDC druntime and not the DMD druntime to see the ARM stuff. GDC/LDC specific stuff is not being upstreamed. There's some ARM asm in GDC:druntime, but we try to rewrite all DMD asm in terms of cross-platform GCC builtins (__builtin_trap instead of asm{int 3;} and so on) so there's really not much ASM left for GDC:druntime.
 - Does GC run reliably on ARM (or is it platform independent)?

to make it work. The source appears to be fairly independent, but other core features like threading or fibers appear not be.

The GC works just fine for GDC/ARM. See my other reply for details. Threading is portable as long as you're on Posix, Fibers in theory as well (there is a backend using posix libc functions and that works fine on ARM. But only recent glibc version > 2.17 implement these functions)
Jan 12 2014
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 10 Jan 2014 08:59:56 +0000
schrieb "Dicebot" <public dicebot.lv>:

 There were people trying vibe.d on ARM/Linux here and there with 
 several issues that may or may not be already fixed by 
 LDC/GDC/vibe.d developers. One thread I have found:
 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/6048/
 
 As far as I know it works in general but using any more complex 
 projects like vibe.d is likely to trigger any hiding  issues in 
 GDC/LDC so one needs to be ready to push through it for greater 
 good.

Interesting, I didn't know about that thread. I tried the vibe-d examples and all of them worked fine, however I didn't do extensive testing. I made a small fix to the fibers code so maybe that fixed the problem. However, fibers are probably a little bit slower that they could be as we use the libc backend and not ARM-specific ASM.
Jan 12 2014
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 09 Jan 2014 19:07:17 +0100
schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:

 Hello,

Answers for GDC:
 I'm developing embedded system product on ARM9/Linux platform and I
 wish I could use D and vibe.d for this task.
 

ARMv5 or ARMv4? I tested ARMv5 and that should work. ARMv4 should work as well but is untested.
 I have couple of questions in this matter:
 - What is the current status of ARM support?

GDC is almost ready ready for a public beta. Tested with Softfloat(no FPU)/Hardfloat on ARMv5/ARMv6: * Compiler test suite passes as well as x86 * Druntime unittests pass * Phobos tests pass except for std.math.internal.gammafunction which isn't ported yet I mainly test using cross-compilers and haven't found any cross-compiler issues so for (cross-compilers also pass all those test mentioned above). The remaining work is getting my changes upstreamed which will probably take 2-4 weeks, then making a public beta with binaries for cross-compilers. See https://github.com/jpf91/GDC/tree/arm-old (old only means gcc-4.8 instead of gcc-4.9)
 - Does GDC support cross-compiling to ARM?

I use and recommend crosstool-NG.
 - Is it possible to remote-debug D code on ARM? (I've used GDB for
 C++ remote debugging on ARM11, I think this should also work with GDC 
 compiled code)

This should work just fine, but I didn't test it. Native debugging works well. (GCC-4.8 emits dwarf4 by default. If your gdb doesn't support dwarf4 you have to pass some flags to gdc to generate dwarf2)
 - Does druntime support ARM plaforms?

compiler so the upstream druntime is not complete. But as dmd doesn't target ARM anyway...)
 - Does phobos support ARM plaforms?

Yes. Phobos is mostly CPU-architecture independent. The biggest problem is usually floating point code which assumes real==80bit. But Iain sorted out most of these issues, only std.math.internal.gammafunction remains.
 - Does GC run reliably on ARM (or is it platform independent)?

stack grows upward/downwards and that's it. It depends on the OS, but only for very few things (getting stack bounds, TLS memory ranges etc). As longs as you use Linux/Glibc it should work just fine.
 - Can you estimate eventual cost of supporting D on ARM (think of
 paid bounty).

Can't speak for anyone else but for me it's more a matter of missing time than of money. Probably donating a board for the auto-tester could help.
Jan 12 2014
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Johannes Pfau wrote:
 Am Thu, 09 Jan 2014 19:07:17 +0100
 schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:

 Hello,

Answers for GDC:
 I'm developing embedded system product on ARM9/Linux platform and I
 wish I could use D and vibe.d for this task.

ARMv5 or ARMv4? I tested ARMv5 and that should work. ARMv4 should work as well but is untested.

It's ARM926EJ-S CPU (ARMv5).
 I have couple of questions in this matter:
 - Can you estimate eventual cost of supporting D on ARM (think of
 paid bounty).

Can't speak for anyone else but for me it's more a matter of missing time than of money. Probably donating a board for the auto-tester could help.

I can do that, but it might be easier to run QEMU tester. QEMU supports emulation of Versatile board with exactly same CPU and it should run at the same speed as the board (~400MHz) on modern x86 machine. What do you think?
Jan 13 2014
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Iain Buclaw wrote:
 QEMU testing is quirky.  If your lucky and get it working, don't make
 any system changes. :o)

What do you mean exactly?
 Saying that, ARM is the only emulation that I've gotten working where
 I've actually built GDC ontop of.

For anyone interested: Here are prebuilt Debian Squeeze(2.6.32) / Wheezy(3.2.0) images for Versatile/QEMU: http://people.debian.org/~aurel32/qemu/armel/ (link taken from http://wiki.redsleeve.org/index.php/QEMU). They should work out of the box :-) Here's guide on emulating Versatile platform (it's based on older Debian Etch): http://www.aurel32.net/info/debian_arm_qemu.php I think GDC should run on plain Debian Wheezy just fine.
Jan 13 2014
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Johannes Pfau wrote:
 Am Mon, 13 Jan 2014 12:25:17 +0100
 schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:

 Iain Buclaw wrote:
 QEMU testing is quirky.  If your lucky and get it working, don't
 make any system changes. :o)

What do you mean exactly?
 Saying that, ARM is the only emulation that I've gotten working
 where I've actually built GDC ontop of.

For anyone interested: Here are prebuilt Debian Squeeze(2.6.32) / Wheezy(3.2.0) images for Versatile/QEMU: http://people.debian.org/~aurel32/qemu/armel/ (link taken from http://wiki.redsleeve.org/index.php/QEMU). They should work out of the box :-) Here's guide on emulating Versatile platform (it's based on older Debian Etch): http://www.aurel32.net/info/debian_arm_qemu.php I think GDC should run on plain Debian Wheezy just fine.

I actually used that VM image some time ago. My main problem was that qemu crashed often, but that could have been my fault.

How long ago? Because these images seem to be updated frequently (actual images are from december 2013). I think I can take a look and prepare working QEMU + VM image for auto tester. I just need some free time...
 Compiling on QEMU is quite slow IIRC, but Brad would have to decide if
 an emulator solution or a real board is better for the auto tester.

Ok, but personally I would never compile on the board (slow!). I would rather use a cross-compiler.
 Do you have any experience with the cubieboard (1)?

Sorry, no.
 I think SATA would
 be quite nice cause SD-cards are a real bottleneck when compiling. But
 I never used one of those boards so I don't know how well they're
 working...

I recall that with Raspberry Pi I was using network file system hosted on my local machine. SD card was used only for boot. It worked pretty good.
Jan 14 2014
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Iain Buclaw wrote:
 On 14 January 2014 22:36, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:
 Johannes Pfau wrote:
 Am Mon, 13 Jan 2014 12:25:17 +0100
 schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:

 Iain Buclaw wrote:
 QEMU testing is quirky.  If your lucky and get it working, don't
 make any system changes. :o)

What do you mean exactly?
 Saying that, ARM is the only emulation that I've gotten working
 where I've actually built GDC ontop of.

For anyone interested: Here are prebuilt Debian Squeeze(2.6.32) / Wheezy(3.2.0) images for Versatile/QEMU: http://people.debian.org/~aurel32/qemu/armel/ (link taken from http://wiki.redsleeve.org/index.php/QEMU). They should work out of the box :-) Here's guide on emulating Versatile platform (it's based on older Debian Etch): http://www.aurel32.net/info/debian_arm_qemu.php I think GDC should run on plain Debian Wheezy just fine.

I actually used that VM image some time ago. My main problem was that qemu crashed often, but that could have been my fault.

How long ago? Because these images seem to be updated frequently (actual images are from december 2013). I think I can take a look and prepare working QEMU + VM image for auto tester. I just need some free time...

It doesn't matter when the images was created, it matters what version of QEMU is running them. :-) I tried those images earlier today for instance, none of them worked on Ubuntu Precise.

It seems that Ubuntu Precise has QEMU 1.0.50, but according to README.TXT which is hosted with those images, you'd need version 1.1.0 or later.
Jan 14 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 13 January 2014 09:05, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:
 Johannes Pfau wrote:
 Am Thu, 09 Jan 2014 19:07:17 +0100
 schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:

 Hello,

Answers for GDC:
 I'm developing embedded system product on ARM9/Linux platform and I
 wish I could use D and vibe.d for this task.

ARMv5 or ARMv4? I tested ARMv5 and that should work. ARMv4 should work as well but is untested.

It's ARM926EJ-S CPU (ARMv5).
 I have couple of questions in this matter:
 - Can you estimate eventual cost of supporting D on ARM (think of
 paid bounty).

Can't speak for anyone else but for me it's more a matter of missing time than of money. Probably donating a board for the auto-tester could help.

I can do that, but it might be easier to run QEMU tester. QEMU supports emulation of Versatile board with exactly same CPU and it should run at the same speed as the board (~400MHz) on modern x86 machine. What do you think?

QEMU testing is quirky. If your lucky and get it working, don't make any system changes. :o) Saying that, ARM is the only emulation that I've gotten working where I've actually built GDC ontop of. Regards Iain
Jan 13 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 1/14/14 11:14 AM, Johannes Pfau wrote:
 I actually used that VM image some time ago. My main problem was that
 qemu crashed often, but that could have been my fault.
 Compiling on QEMU is quite slow IIRC, but Brad would have to decide if
 an emulator solution or a real board is better for the auto tester.

 Do you have any experience with the cubieboard (1)? I think SATA would
 be quite nice cause SD-cards are a real bottleneck when compiling. But
 I never used one of those boards so I don't know how well they're
 working...

It'd actually be whoever donates the equipment to run the auto-tester on. I don't care if I'm logging into a virtual or physical box, as long as it supports ssh and the other requirements of the test system. I've used both in the past. On modern arm, I suspect it'd be significantly faster than even a very fast x86 box emulating an arm system, but I'm not picky.
Jan 14 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 14 January 2014 22:36, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:
 Johannes Pfau wrote:
 Am Mon, 13 Jan 2014 12:25:17 +0100
 schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:

 Iain Buclaw wrote:
 QEMU testing is quirky.  If your lucky and get it working, don't
 make any system changes. :o)

What do you mean exactly?
 Saying that, ARM is the only emulation that I've gotten working
 where I've actually built GDC ontop of.

For anyone interested: Here are prebuilt Debian Squeeze(2.6.32) / Wheezy(3.2.0) images for Versatile/QEMU: http://people.debian.org/~aurel32/qemu/armel/ (link taken from http://wiki.redsleeve.org/index.php/QEMU). They should work out of the box :-) Here's guide on emulating Versatile platform (it's based on older Debian Etch): http://www.aurel32.net/info/debian_arm_qemu.php I think GDC should run on plain Debian Wheezy just fine.

I actually used that VM image some time ago. My main problem was that qemu crashed often, but that could have been my fault.

How long ago? Because these images seem to be updated frequently (actual images are from december 2013). I think I can take a look and prepare working QEMU + VM image for auto tester. I just need some free time...

It doesn't matter when the images was created, it matters what version of QEMU is running them. :-) I tried those images earlier today for instance, none of them worked on Ubuntu Precise.
Jan 14 2014
prev sibling parent "Kira Backes" <kira.backes nrwsoft.de> writes:
Now is the time when ARM may become really important:
http://arstechnica.com/information-technology/2014/01/amd-reveals-its-first-arm-processor-8-core-opteron-a1100/
Jan 29 2014
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Sunday, 12 January 2014 at 11:31:07 UTC, Johannes Pfau wrote:
 Am Fri, 10 Jan 2014 08:27:37 +0000
 schrieb "Joakim" <joakim airpost.net>:
 - Does druntime support ARM plaforms?

amount of x86 assembly, but I have not yet looked into how much of that is optimization and therefore not strictly necessary to reimplement on ARM.

You'll have to look at GDC/LDC druntime and not the DMD druntime to see the ARM stuff. GDC/LDC specific stuff is not being upstreamed. There's some ARM asm in GDC:druntime, but we try to rewrite all DMD asm in terms of cross-platform GCC builtins (__builtin_trap instead of asm{int 3;} and so on) so there's really not much ASM left for GDC:druntime.

I didn't know that ldc and gdc used their own forks of druntime and phobos, so maybe my info is a bit off.
Jan 12 2014
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Mon, 13 Jan 2014 12:25:17 +0100
schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:

 Iain Buclaw wrote:
 QEMU testing is quirky.  If your lucky and get it working, don't
 make any system changes. :o)

What do you mean exactly?
 Saying that, ARM is the only emulation that I've gotten working
 where I've actually built GDC ontop of.

For anyone interested: Here are prebuilt Debian Squeeze(2.6.32) / Wheezy(3.2.0) images for Versatile/QEMU: http://people.debian.org/~aurel32/qemu/armel/ (link taken from http://wiki.redsleeve.org/index.php/QEMU). They should work out of the box :-) Here's guide on emulating Versatile platform (it's based on older Debian Etch): http://www.aurel32.net/info/debian_arm_qemu.php I think GDC should run on plain Debian Wheezy just fine.

I actually used that VM image some time ago. My main problem was that qemu crashed often, but that could have been my fault. Compiling on QEMU is quite slow IIRC, but Brad would have to decide if an emulator solution or a real board is better for the auto tester. Do you have any experience with the cubieboard (1)? I think SATA would be quite nice cause SD-cards are a real bottleneck when compiling. But I never used one of those boards so I don't know how well they're working...
Jan 14 2014