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?
- 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)
- 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?
A bit of context: I've been updating the inline asm array ops
code in druntime (e.g. a[] += b[];) and managing to outpace gdc's
codegen by - in some cases - a factor of 5. I'm very surprised by
this, but as far as I can tell I'm not making any mistakes with
the benchmarking. This is with the latest gdc with gcc4.9
snapshot (-O3 -frelease -fno-bounds-check), compared with the
latest ldc and dmd.
If my work gets merged in to druntime*, it could leave a
situation where gdc loses out.
*some preliminary work can be seen here, although I have made
some significant changes I haven't pushed yet:
https://github.com/D-Programming-Language/druntime/pull/471
