Inherent code performance advantages of D over C?

Paulo Pinto pjmlp at progtools.org
Fri Dec 13 06:30:21 PST 2013


On Friday, 13 December 2013 at 13:57:09 UTC, Marco Leise wrote:
> Am Thu, 12 Dec 2013 12:46:26 -0800
> schrieb Walter Bright <newshound2 at digitalmars.com>:
>
>> On 12/12/2013 12:33 PM, Max Samukha wrote:
>> > Don't you find it somewhat alarming that both alternative 
>> > compilers follow
>> > neither the standard inline asm nor ABI?
>> 
>> I find it unfortunate. But it also can be difficult and time 
>> consuming to reimplement an assembler for those back ends, so 
>> I can understand why it isn't a priority.
>
> It's not just that. I found that some discussion and work is
> necessary about these issues, if D is ever going to have a
> standard inline assembly language:
>
> * GCC would have to support naked functions on x86/amd64 or DMD
>   drop the keyword.
> * DMD would have to adapt extended inline assembly expressions
>   or the GDC/LDC "downgrade" to basic inline assembly.
>
> A "downgrade" needs good arguments though. Not only did D
> evolve over C, but the same is true for inline assembly. From
> http://wiki.dlang.org/LDC_inline_assembly_expressions:
>
>   Being an expression, extended inline expressions are able to
>   return values!
>
>   Additionally issues regarding inlining of function containing
>   inline asm are mostly not relevant for extended inline 
> assembly
>   expressions. Effectively, extended inline assembly expression
>   can be used to efficiently implement new intrinsics in the
>   compiler.


Maybe the best way to fix this issue is to follow what other
language standards do (C++, Ada) and only define that inline
assembly is possible and how the entry point, e.g. asm () looks
like.

The real inline assembly syntax is then left implementation
specific.


--
Paulo


More information about the Digitalmars-d mailing list