Maybe I'm somewhat disturbed but I'd rather go the other way round, i.e. (ab)use D as a comfortable and less error prone way to create C Code. But oh well that's wet dreaming anyway for quite some time.
To your questions: Considering that you are new to D (like myself), come from gnu compiler world and are doing embedded, you will most likely be used to and want debugging. Therefore -> GDC. It's simply the only option that allows for painless debugging. Furthermore, support by the developer(s) is excellent and friendly. DMD is the ref. and is, besides some quirks, nicely working and uncannily fast. LDC (haven't had a closer look at it myself) is interesting for llvm alone. Right now, though, GDC is what you might want to have good look at. Ad "GC": As some pros already indicated, it's possible; well, many things are possible - but it wise? I think it depends a whole lot on factors like CPU, RAM, RT'ness. For something highly RT critical on a 16bit, 20K RAM MCU GC is a no-go and so quite probably is D. For a "fat" Cortex M4 or a SPARC (what a beauty!) with RAM in the MB range and real-time needs/criticality being not so high or even sporadic D could quite well be the way to go, if only phobos were completely ported. Even a certain level of RT-crit. must not necessarily be a reason to stay away from D, if e.g. one could split the job in a low layer C and the major part in D with all its strengths and comfort. In summary though, it - unfortunately - seems somewhat early to switch to D for embedded on Arm and Sparc. Should you learn D or at least have an extended look at it, anyway? Definitely yes. And if it was only to see what's possible, how C-like programming can and should be done, and to better and more deeply understand paradigms and concepts related to reliability. A+ -R
