Future of D on alternate platforms

Joakim joakim at airpost.net
Sat Feb 22 10:44:41 PST 2014


On Friday, 21 February 2014 at 20:55:58 UTC, Frustrated wrote:
> How difficult is it to port D code to future projects on
> alternate platforms(mainly coming from win) and, if needed be, a
> compiler for those platforms?
>
> At this point, I'm wondering how difficult code I'm writing for
> windows will be to port to, say, the iOS, mac, arm, and more
> likely, embedded systems such as the tigerSharc, etc.
Well, there is a Mac compiler, you could try it out and see. ;) 
As for the rest, they're being actively developed, but certainly 
not ready yet.

> I've heard many times the LLVM compiler mentioned in the forums
> and it seems to be able to compile D code to any platform the
> compiler supports(but somehow independent of D... maybe it
> compiles it to an intermediate language?).
Yes, LDC can generate native code for many architectures, but 
that's only the base of platform support.  There are many other 
integration issues.  But that hasn't stopped the LDC developers 
from providing decent support for linux/PowerPC, for example:

http://wiki.dlang.org/LDC

> My goal at this point is to use D on windows to create some
> algorithmic software and then potentially port it to some
> embedded system with minimal rewrite of the core code. e.g., I
> don't want to have to rewrite the algorithms in C and use the
> compiler tools for that system. If that was the case there is
> little reason to use D in the first place.
I think it depends on the embedded system.  D obviously doesn't 
support anywhere near the number of platforms as C/C++, at least 
not yet.

> Obviously there is no magic compiler that will do it all. I'm
> curious though as to the possibility. In 2 years could one 
> expect
> D to be more widely used on other systems? I see people already
> getting D started on ARM and iOS so it seems feasible that in 
> the
> near future it would be relatively easy to port the
> code(obviously there are functional differences due to the OS 
> but
> I'm talking about the cpu issues at this point).
Nobody can look into the future.  It looks like good progress is 
being made, but no promises can be made.  Given the amount of 
architectures that llvm supports, I don't think code generation 
for different CPUs will be the problem, more likely OS 
integration issues.  Depending on the platform, you may have to 
roll your sleeves up and pitch in.


More information about the Digitalmars-d mailing list