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 reply "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:


Like Mike, I'm an interested user, who wants to see D on ARMv7, 
not a core developer, but I'll take a shot at answering your 
questions.


 - What is the current status of ARM support?


Limited.  The reference DMD compiler has no support for ARM, 
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?


I've never tried it, but they do claim some support.


 - 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've been thinking about looking into this myself, for my work on 
Android/x86, but I have not done so.


 - Does druntime support ARM plaforms?


Grepping through the code, druntime appears to use a fair 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.


 - Does phobos support ARM plaforms?


Phobos appears to be largely arch-independent by comparison, but 
still supports x86 best in the cases where it isn't.


 - Does GC run reliably on ARM (or is it platform independent)?


I don't think anybody can know for sure, since nobody has tried 
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).


Not sure.
Jan 10 2014
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?


 Grepping through the code, druntime appears to use a fair 
 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.


Sorry, I should have also said that there is some limited ARM 
support, mostly just translating arch-dependent headers, in 
druntime.
Jan 10 2014
prev sibling parent reply 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:


 Like Mike, I'm an interested user, who wants to see D on ARMv7, 
 not a core developer, but I'll take a shot at answering your 
 questions.
 

 - What is the current status of ARM support?


 Limited.  The reference DMD compiler has no support for ARM, 
 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?


 Grepping through the code, druntime appears to use a fair 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. 



 - Does GC run reliably on ARM (or is it platform independent)?


 I don't think anybody can know for sure, since nobody has tried 
 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
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?


 Grepping through the code, druntime appears to use a fair 
 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 next sibling parent reply "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
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 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?


Yes, that works just fine. See http://wiki.dlang.org/GDC/Cross_Compiler
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?


Yes (the druntime in gdc. We only upstream things that work for every
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)?


Yes. It's basically CPU-arch independent. You need to tell it if the
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
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 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
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 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
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 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 reply 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
parent reply 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
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