[Issue 2191] GDC fraudulently defines D_InlineAsmX86

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Aug 25 00:26:39 PDT 2008


http://d.puremagic.com/issues/show_bug.cgi?id=2191





------- Comment #2 from clugdbug at yahoo.com.au  2008-08-25 02:26 -------
(In reply to comment #1)
> I think this bug is invalid. The spec says about "the D_InlineAsmX86" version,
> that is specifies that inline asm is supported.
> 
> Looking at the inline asm page, at the top it says "Differing D
> implementations, however, are free to innovate upon the memory model, function
> call/return conventions, argument passing conventions, etc.".

Read the previous paragraph. That means "different from Pentium". It does not
mean "different from DMD".

D_InlineAsmX86 _has_ to mean "inline X86 asm will work".

> To me this means that the ABI documentation (which is mostly TDB anyway), is a
> recommendation, not a requirement. As such I'd recommend a new version like
> D_ABICompliant, or something.
> 
> I'm currently working on ABI conformance in LLVMDC for x86, hence my interest
> in this ticket.
> 
> While I see the value of ABI conformance, in the case of LLVMDC, it can mean
> (probably) significant performance decrease as we can no longer tell it to use
> the 'fastest' calling convention for extern(D).

Differing ABIs are a catastrophe. They are one of the worst mistakes of C++. I
cannot stress this strongly enough. If you have a different ABI, you have a
different language. 

(It's really obvious in the case of inline asm, where you need to write
different asm code for every different calling convention).

Note, though, that the D ABI only applies to X86_32. Since nothing is defined
for X86-64, you're free to innovate. (For example, on AMD64, using XMM
registers
for parameter passing).


-- 



More information about the D.gnu mailing list