On 8 April 2013 17:55, John Colvin <john.loughran.col...@gmail.com> wrote:
> On Monday, 8 April 2013 at 15:29:13 UTC, Iain Buclaw wrote: > >> On 8 April 2013 15:49, John Colvin >> <john.loughran.colvin@gmail.**com<john.loughran.col...@gmail.com>> >> wrote: >> >> On Monday, 8 April 2013 at 00:13:29 UTC, Iain Buclaw wrote: >>> >>> If only that logic held water... >>>> >>>> GDC actually provided the implementation of iasm to LDC. Reasons why it >>>> was yanked out. >>>> - one big ugly x86 special case. >>>> >>>> >>> Fair enough, although I see no reason why Ds iasm shouldn't be extended >>> to >>> support other architectures in the future. >>> >>> >>> - depended on backend headers poisoned for use in the frontend. >>> >>>> >>>> >>> when you say poisoned, I presume you mean by the license? >>> >>> >>> From system.h >>> >> --- >> /* Front ends should never have to include middle-end headers. Enforce >> this by poisoning the header double-include protection defines. */ >> #ifdef IN_GCC_FRONTEND >> #pragma GCC poison GCC_RTL_H GCC_EXCEPT_H GCC_EXPR_H >> #endif >> --- >> >> The implementation of IASM required access to rtl.h and expr.h - which is >> able to give you information about stack layout, etc. >> >> >> >> >> >>> - frontend should not know or care about what arch it is targeting. >>> >>>> >>>> >>> what about all the other arch specific version statements? e.g. >>> version(ARM) >>> >>> >>> They are handled in the backend via a macro: TARGET_CPU_D_BUILTINS, >> TARGET_OS_D_BUILTINS. >> >> If defined, these provide the frontend all version conditions without the >> frontend having a large portion of code #ifdef'ing all over the place. >> >> >> >> >> - most iasm in druntime/phobos rely on dmd's non-standard calling >>> >>>> convention. >>>> - it has been argued in the past that gdc should not define >>>> D_InlineAsm_X86 if it does not follow dmd's ABI. >>>> >>>> >>> Is it a feasible idea to automatically convert dmds inline asm to gcc's >>> extended inline asm? >>> >>> >>> This is what it did. However as stated about it depended on poisoned >> backend headers in order to get the correct information. >> >> >> >> Regards >> > > > So, overall, it's not gonna happen unless dmd changes its implementation > of inline asm? > Pretty much. Though given that what you have changed is in rt folders, I think the intent is that each compiler maintains its own, so it wouldn't be difficult just to re-implement using extended assembler. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
