<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 April 2013 15:49, John Colvin <span dir="ltr"><<a href="mailto:john.loughran.colvin@gmail.com" target="_blank">john.loughran.colvin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Monday, 8 April 2013 at 00:13:29 UTC, Iain Buclaw wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If only that logic held water...<br>
<br>
GDC actually provided the implementation of iasm to LDC.  Reasons why it<br>
was yanked out.<br>
- one big ugly x86 special case.<br>
</blockquote>
<br></div>
Fair enough, although I see no reason why Ds iasm shouldn't be extended to support other architectures in the future.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- depended on backend headers poisoned for use in the frontend.<br>
</blockquote>
<br></div>
when you say poisoned, I presume you mean by the license?<div class="im"><br></div></blockquote><div><br></div><div>From system.h<br>---<br>/* Front ends should never have to include middle-end headers.  Enforce<br>   this by poisoning the header double-include protection defines.  */<br>
#ifdef IN_GCC_FRONTEND<br>#pragma GCC poison GCC_RTL_H GCC_EXCEPT_H GCC_EXPR_H<br>#endif<br>---<br><br></div><div>The implementation of IASM required access to rtl.h and expr.h - which is able to give you information about stack layout, etc.<br>
</div><br><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- frontend should not know or care about what arch it is targeting.<br>
</blockquote>
<br></div>
what about all the other arch specific version statements? e.g. version(ARM)<div class="im"><br></div></blockquote><div><br></div><div>They are handled in the backend via a macro: TARGET_CPU_D_BUILTINS, TARGET_OS_D_BUILTINS.<br>
<br></div><div>If defined, these provide the frontend all version conditions without the frontend having a large portion of code #ifdef'ing all over the place.<br><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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.<br>
</blockquote>
<br></div>
Is it a feasible idea to automatically convert dmds inline asm to gcc's extended inline asm?<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">This is what it did.  However as stated about it depended on poisoned backend headers in order to get the correct information.<br></div><div class="gmail_extra"><br clear="all">
<br><br></div><div class="gmail_extra">Regards<br></div><div class="gmail_extra">-- <br>Iain Buclaw<br><br>*(p < e ? p++ : p) = (c & 0x0f) + '0';
</div></div>