Jump to page: 1 2
Thread overview
ARM support
Jan 09, 2014
Piotr Szturmaj
Jan 10, 2014
Mike
Jan 10, 2014
Joakim
Jan 10, 2014
Joakim
Jan 12, 2014
Johannes Pfau
Jan 12, 2014
Joakim
Jan 10, 2014
Dicebot
Jan 12, 2014
Johannes Pfau
Jan 12, 2014
Johannes Pfau
Jan 13, 2014
Piotr Szturmaj
Jan 13, 2014
Iain Buclaw
Jan 13, 2014
Piotr Szturmaj
Jan 14, 2014
Johannes Pfau
Jan 14, 2014
Brad Roberts
Jan 14, 2014
Piotr Szturmaj
Jan 14, 2014
Iain Buclaw
Jan 14, 2014
Piotr Szturmaj
Jan 29, 2014
Kira Backes
January 09, 2014
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.
January 10, 2014
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.
January 10, 2014
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.
January 10, 2014
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.
January 10, 2014
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.
January 12, 2014
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)

January 12, 2014
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.
January 12, 2014
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.
January 12, 2014
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.
January 13, 2014
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?
« First   ‹ Prev
1 2