<p><br>
On Apr 8, 2013 12:10 AM, "John Colvin" <<a href="mailto:john.loughran.colvin@gmail.com">john.loughran.colvin@gmail.com</a>> wrote:<br>
><br>
> On Sunday, 7 April 2013 at 23:02:28 UTC, John Colvin wrote:<br>
>><br>
>> void main() {<br>
>>         version(D_InlineAsm_X86_64) {<br>
>>                 pragma(msg,"x64");<br>
>>         }<br>
>>         else version(D_InlineAsm_X86) {<br>
>>                 pragma(msg,"x86");<br>
>>         }<br>
>>         else {<br>
>>                 pragma(msg,"None");<br>
>>         }<br>
>> }<br>
>><br>
>> dmd/ldc -m64: x64<br>
>> gdc -m64/32 : None<br>
><br>
><br>
> Ah, I see D inline asm isn't supported in gdc. When I removed the version check from my code I got a massive slew of errors telling me so (one for every asm line, not one per asm block).<br>
><br>
> What's stopping iasm in gdc, ldc appears to have no problem.</p>
<p>If only that logic held water...</p>
<p>GDC actually provided the implementation of iasm to LDC.  Reasons why it was yanked out. <br>
- one big ugly x86 special case.<br>
- depended on backend headers poisoned for use in the frontend. <br>
- frontend should not know or care about what arch it is targeting.<br>
- likewise, use of TARGET_ macros is tabooed in gcc frontends. <br>
- most iasm in druntime/phobos rely on dmd's non-standard calling convention.<br>
- it has been argued in the past that gdc should not define D_InlineAsm_X86 if it does not follow dmd's ABI.</p>
<p>Could probably think of a few dozen more to throw at you. </p>
<p>Regards<br>
-- <br>
Iain Buclaw</p>
<p>*(p < e ? p++ : p) = (c & 0x0f) + '0';<br>
</p>