xdc: A hypothetical D cross-compiler and AST manipulation tool.

[Chad Joan]

On Thursday, 18 July 2013 at 10:26:24 UTC, Kagamin wrote:
> llvm should be platform-independent enough, so you have ldc. 
> But the problem with D is that it has more features than C/C++, 
> so if you output C code you can only use C features, or you 
> have to implement druntime+phobos for the target platform, 
> which doesn't come for free.

I think a C backend would get us farther than an LLVM backend.  
Imagine targeting one of the ubiquitous ARM targets like Android, 
and its gazillion variants.  LLVM has an ARM target I'm pretty 
sure, but the Android community uses GCC as their compiler.  This 
puts LLVM/LDC on Android into a "may or may not work" category 
(unless they've done it already while I wasn't looking).  
Emitting C/C++ code and feeding it to the Android NDK though: 
that will work for sure, or at least land incredibly close.  
Rinse and repeat for PIC, Cypress, iPhone, XBox (any of them), 
Wii, Ouya, PS3, PS4, 3DS, and whatever else might come out a year 
from now.  I suspect that LLVM will be missing support for a 
bunch of those, and lag new platforms significantly; not unless 
it just happens to exist in their "ecosystem".

I think that LLVM might have a maintained C backend again.  It 
had been unmaintained/unsupported for a while.  If someone thinks 
that using LLVM's C backend makes more sense, then they should do 
it with LDC.  I'd be really happy about it, because I want that 
functionality.

I am not interested in using LLVM as my /first/ backend in xdc 
for a combination of the above reasons and their implications:
.- LLVM emitting native code for xdc will require someone
.    knowledgable with LLVM to set things up and potentially
.    spend time on it if the target platform requires tweaking.
.    Getting handed a file full of C code requires only knowledge
.    of how to use the C compiler on the target system.
.- LLVM emitting C code should probably be done by ldc instead.
.- LLVM emitting C code would also add unnecessary layers:
.    D->AST->LLVM_IR->C vs D->AST->C.
.    This extra layer can lose information.

You are right that druntime+phobos don't come for free.  Doing 
complete ports of those to platform X is outside the scope of 
this project.  I do intend to salvage whatever parts of them I 
can in a portable manner.  Moreover, I intend xdc to have the 
capability to toggle druntime/phobos features on and off easily 
based on existing support for the intended platform.  The 
C-Windows target would probably have more druntime/phobos 
features enabled than C-Android target.  I'd like to make sure 
that anyone can use what's available, and if not, still be 
allowed to access the platform.  I don't think it makes sense 
that I'd be completely unable to write iPhone code just because 
there isn't GC/threading code available for it in the runtime 
yet; I should be able to do some non-trivial things without 
those.  Note that a reference-counting implementation would be 
portable everywhere that doesn't have a native GC, so you'd never 
have anything less than that (unless you intentionally ditched 
it, ex: memory limited microcontrollers where things are 
statically allocated anyways).

To be more concrete, I intend to make it possible to invoke xdc 
with "hints", like so:
xdc --emit=C89 --hostc=gcc --os=windows --threads=pthreads main.d
# Breakdown:
# --emit=C89 causes C89 compliant code to be emitted.
# --hostc=gcc causes xdc to feed the C89 code to gcc (mingw).
# --os=windows causes xdc to use WinAPI by default for
#     for implementing druntime and platform-specific language
#     features.
# --threads=pthreads overrides the use of Windows threads;
#     posix threads are used instead.
# This combination could probably land GC+threading and mesh well
#   with a mingw environment.

Alternatively, it could be invoked like this:
xdc --emit=C89 main.d
# This will generate some very conservative C89 code.
# You will have refcounting instead of GC, and thread spawning
#   won't work.
# However, you'll have some really freakin' portable code!

Even with a conservative target like C89-only, there are still an 
incredibly large number of extremely useful D features (OOP, 
templates, scope(exit), CTFE, mixins, ranges, op-overloading, 
etc) that DO come for free.  These can be lowered into C code 
that does the same thing but looks uglier.  Such lowered code 
would take much longer for a human to write and become tedious to 
maintain, but a compiler can do it tirelessly.