<p>On Dec 23, 2013 12:00 AM, "bearophile" <<a href="mailto:bearophileHUGS@lycos.com">bearophileHUGS@lycos.com</a>> wrote:<br>
><br>
> Iain Buclaw:<br>
><br>
><br>
>> That same support is never going to happen.  Not because of<br>
>> disagreement, but because our backends are designed to work most<br>
>> naturally in conflicting ways.<br>
><br>
><br>
> I think this means that working to make DMD better is a good idea, because every compiler has different strengths, like Walter says.<br>
><br>
></p>
<p>For inline assembly, making dmd work better how?</p>
<p>The problem with inline assembly is much more fundamental. DMD emits object code, so it makes sense to have a full blown assembler built into it.  In contrast, GDC emits assembly, and AT&T syntax at that, so having anything other than GCC-style inline assembly support is just plain awkward.</p>

<p>>> and that core.simd.__simd thingy.<br>
><br>
><br>
> What are the problems with that thing?<br>
></p>
<p>Not possible without some sort of translation map, which would be target specific, so not suitable for GDC, and language specific so not suitable for GCC either.</p>
<p>Also, falls under category of x86-centric below.</p>
<p>><br>
>> x86-specific and x86-centric are implied on all DMD's features mentioned above.<br>
><br>
><br>
> While the work to support other CPUs (and GPUs) is important, even at Phobos/language level, x86 is still an important CPU, so the work to make its support good is not wasted time :-)<br>
></p>
<p>Indeed, but just keep that support out of the language spec, as it only serves to hurt progress, and leads to extreme conflicts in design (I don't tend to show it, but I do take extreme pity that DMD has three interfaces to va_arg - X86, X86_64, and Win64).</p>

<p>Regards<br>
-- <br>
Iain Buclaw</p>
<p>*(p < e ? p++ : p) = (c & 0x0f) + '0';</p>