On Monday, 8 April 2013 at 15:29:13 UTC, Iain Buclaw wrote:
On 8 April 2013 15:49, John Colvin
<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?
