Inherent code performance advantages of D over C?

[Iain Buclaw]

On 14 December 2013 17:44, Walter Bright <newshound2 at digitalmars.com> wrote:
> On 12/14/2013 6:08 AM, Iain Buclaw wrote:
>>
>> The implementation of which existed in GDC first, and was released as
>> dual GPL/BSD license to allow into LDC devs to use and improve (they
>> added 64bit assembler support for instance, years before DMD got 64bit
>> support),
>
>
> I didn't know this, thanks for telling me.
>
>
>> and then subsequently dropped from GDC for a number of valid
>> reasons:
>>
>> 1) Transition towards making a platform/target agnostic frontend
>> implementation.
>>
>> 2) Don't and will never implement the DMD-style calling convention, so
>> all inline assembly in druntime and phobos actually doesn't work with
>> GDC - there's actually a bug report about GDC incorrectly pre-defining
>> D_InlineAsm and friends because of this.
>
>
> dmd's works on multiple platforms and uses version statements to account for
> ABI differences. It's still easier than having a different syntax.
>

What I meant was that despite being able to handle IASM syntax at one
time. eg: std.math or core.cpuid was altered to specifically work with
the ABI GDC used on x86 (cdecl).  This was especially noticed from
naked assembly, or normal assembly that assumed eg: EAX or the ST
registers would be left untouched by the compiler on exiting the
function.


>
>> 3) It is a really big WAT on having two conflicting styles, one for
>> x86, another for everything else.
>
>
> gcc gets them wrong for everything else, too :-)
>

>From an implementors point of view, it's easier to pass off inline
assembly directly to the assembler, rather than try to manage it in
the compiler.

I honestly don't know how one would be able to make AsmStatement work
for non-x86 architectures.  At least this is not possible in GDC
unless you want to resort to doing things in a way that are shamed
upon (like checking the definition of a particular TARGET macro :)