On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
> On 19-06-2012 23:52, Walter Bright wrote:
>> On 6/19/2012 1:36 PM, bearophile wrote:
>>>> No, but the idea was to allow D to innovate on calling
>>>> conventions without disturbing code that needed to
>>>> interface with C.
>>>
>>> The idea is nice, but ideas aren't enough. Where are the benchmarks
>>> that show a
>>> performance improvement over the C calling convention? And even if such
>>> improvement is present, is it worth it in the face of people that
>>> don't want to
>>> add it to GCC?
>>
>> GDC can certainly define its D calling convention to match GCC's. It's
>> an "implementation defined" thing, not a language defined one.
>>
>
> Then let's please rename it to the DMD ABI instead of calling it the D
> ABI and making it look like it's part of the language on the website.
> Further, D mangling rules should be separate from calling convention.
>

IIRC currently, the calling convention is mangled into the symbol name.
Do you want to remove this?

On 20-06-2012 01:55, Timon Gehr wrote:
> On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
>> On 19-06-2012 23:52, Walter Bright wrote:
>>> On 6/19/2012 1:36 PM, bearophile wrote:
>>>>> No, but the idea was to allow D to innovate on calling
>>>>> conventions without disturbing code that needed to
>>>>> interface with C.
>>>>
>>>> The idea is nice, but ideas aren't enough. Where are the benchmarks
>>>> that show a
>>>> performance improvement over the C calling convention? And even if such
>>>> improvement is present, is it worth it in the face of people that
>>>> don't want to
>>>> add it to GCC?
>>>
>>> GDC can certainly define its D calling convention to match GCC's. It's
>>> an "implementation defined" thing, not a language defined one.
>>>
>>
>> Then let's please rename it to the DMD ABI instead of calling it the D
>> ABI and making it look like it's part of the language on the website.
>> Further, D mangling rules should be separate from calling convention.
>>
>
> IIRC currently, the calling convention is mangled into the symbol name.
> Do you want to remove this?

Not that I can see from http://dlang.org/abi.html ?

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

Manu:

> Properly implemented multiple-return-values being the killer app here!
> Using ALL the argument registers for returning multiple values aswell ;)

Well, if D has a specific calling convention, it's better for it
to give a lot back.

Regarding the LLVM back-end for Haskell, it has required a new
calling convention, used to replace a feature of GCC (missing in
D and in LLVM) ("Thankfully GCC offers an extension, 'Global
Register Variables', which allows you to assign a global variable
to always reside in a specific hardware register"):

http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html

Bye,
bearophile

On 6/19/2012 3:55 PM, Manu wrote:
> On 20 June 2012 01:07, Walter Bright <newshound2@digitalmars.com
>     Do a grep for "naked" across the druntime library sources. For example, its
>     use in druntime/src/rt/alloca.d, where it is very much needed, as alloca()
>     is one of those "magic" functions.
> I never argued against naked... I agree it's mandatory.

Then I misunderstood you.


>     Do a grep for "asm" across the druntime library sources. Can you justify all
>     of that with some other scheme?
>
>
> I think almost all the blocks I just browsed through could be easily written
> with nothing more than the register alias feature I suggested, and perhaps a
> couple of opcode intrinsics.

But I see nothing gained by that.


> And as a bonus, they would also be readable.

I don't agree. The point of IA to me is so I can specify exactly what I want. If I wanted to do it at a higher level, I'd use normal D syntax.


> I can imagine cases where the
> optimiser would have more freedom too.

But if I'm writing IA, I want to do it my way. Not the optimizer's way, which may or may not be able to give me what I want.


>         Thinking more about the implications of removing the inline asm, what would
>         REALLY roxors, would be a keyword to insist a variable is represented by a
>         register, and by extension, to associate it with a specific register:
>
>
>     This was a failure in C.
>
>
> Really?

Yes. C has a register keyword, and nobody uses it anymore. The troubles are many, starting with people always "register"ed the wrong variables, and it really didn't work out too well when compilers started doing live range register assignments. It's ignored by modern C compilers, and hasn't been carried forward into other languages.

> This is the missing link between mandatory asm blocks, and being able to
> do it in high level code with intrinsics.
> The 'register' keyword was similarly fail as 'inline'.. __forceinline was not
> fail, it is actually mandatory. I'd argue that __forceregister would be
> similarly useful in C aswell, but the real power would come from being able to
> specify the particular register to alias.
>
>         This would almost entirely eliminate the usefulness of an inline assembler.
>         Better yet, this could use the 'new' attribute syntax, which most agree will
>         support arguments:
>         @register(rsp) int x;
>
>
>     Some C compilers did have such pseudo-register abilities. It was a failure
>     in practice.
>
>
> Really? I've never seen that. What about it was fail?

It's actually in DMC, believe it or not. It was a giant failure because nobody used it. It was in Borland's TurboC, too. It pretty much just throws a wrench into the gears of more sophisticated code generators.


>     I really don't understand preferring all these rather convoluted
>     enhancements to avoid something simple and straightforward like the inline
>     assembler. The use of IA in the D runtime library, for example, has been
>     quite successful.
>
>
> I agree, IA is useful and has been successful, but it has drawbacks too.
>    * IA ruins optimisation around the IA block

dmd's optimizer is not so sensitive to that.

>    * IA doesn't inline well.

True, but that's fixable (excluding naked functions). Currently, you can use mixins to do it.

> intrinsics allow much greater opportunity for
> efficient integration into the calling context
>    * most IA functions are small, and prime candidates for inlining (see points
> 1 and 2)
>    * IA is difficult for the majority of programmers to follow/understand

IA isn't for everyone. But when you do need it, it has been a marvelous tool for D.

>    * even to experienced programmers, poorly commented asm takes a lot of time
> to mentally parse
>
> It's a shame that there are IA constructs that can't be expressed any other way.
> I don't think it would take much to address that.
>


> This one seems trivial, you just need one intrinsic:
>
>    size_t reqsize = size * newcapacity;
>    __jc(&Loverflow);

That's highly risky. The optimizer knows nothing at all about the state of the flags register, and does not take into account a dependency on the C flag when doing code motion. Nor would the compiler guarantee that the C flag is even set by however it chose to do the previous multiply (for example, the LEA instruction is often used to do multiplies, which leaves the C flag untouched. Oops!). Nothing connects the __jc intrinsic to that multiply operation.


>  Although it depends on a '&codeLabel' mechanism to get the label address (GCC
> supports this in C, I'd love to see this in D too).

Note that supporting such will wind up disabling a lot of the data flow analysis, which is not set up to handle unknown edges between basic blocks.

To summarize, I see a lot of complex new features, a significant rewrite of the optimizer, and a rewrite of a lot of existing code, and at the end of all that we're pretty much at the same state we are at now.

On 06/20/2012 02:04 AM, Alex Rønne Petersen wrote:
> On 20-06-2012 01:55, Timon Gehr wrote:
>> On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
>>> On 19-06-2012 23:52, Walter Bright wrote:
>>>> On 6/19/2012 1:36 PM, bearophile wrote:
>>>>>> No, but the idea was to allow D to innovate on calling
>>>>>> conventions without disturbing code that needed to
>>>>>> interface with C.
>>>>>
>>>>> The idea is nice, but ideas aren't enough. Where are the benchmarks
>>>>> that show a
>>>>> performance improvement over the C calling convention? And even if
>>>>> such
>>>>> improvement is present, is it worth it in the face of people that
>>>>> don't want to
>>>>> add it to GCC?
>>>>
>>>> GDC can certainly define its D calling convention to match GCC's. It's
>>>> an "implementation defined" thing, not a language defined one.
>>>>
>>>
>>> Then let's please rename it to the DMD ABI instead of calling it the D
>>> ABI and making it look like it's part of the language on the website.
>>> Further, D mangling rules should be separate from calling convention.
>>>
>>
>> IIRC currently, the calling convention is mangled into the symbol name.
>> Do you want to remove this?
>
> Not that I can see from http://dlang.org/abi.html ?
>

TypeFunction:
    CallConvention FuncAttrs Arguments ArgClose Type

CallConvention:
    F // D
    U // C
    W // Windows
    V // Pascal
    R // C++

On 6/19/2012 3:47 PM, Alex Rønne Petersen wrote:
> On 19-06-2012 23:52, Walter Bright wrote:
>> GDC can certainly define its D calling convention to match GCC's. It's
>> an "implementation defined" thing, not a language defined one.
> Then let's please rename it to the DMD ABI instead of calling it the D ABI
> and
> making it look like it's part of the language on the website.

The ABI is not part of the language. For example, the C Standard says nothing whatsoever about the C ABI.

> Further, D mangling rules should be separate from calling convention.

I disagree. The mangling rules are not part of the language specification, either. But they are necessary so that a function with one convention won't be connected to one with another.

On 20-06-2012 02:58, Timon Gehr wrote:
> On 06/20/2012 02:04 AM, Alex Rønne Petersen wrote:
>> On 20-06-2012 01:55, Timon Gehr wrote:
>>> On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
>>>> On 19-06-2012 23:52, Walter Bright wrote:
>>>>> On 6/19/2012 1:36 PM, bearophile wrote:
>>>>>>> No, but the idea was to allow D to innovate on calling
>>>>>>> conventions without disturbing code that needed to
>>>>>>> interface with C.
>>>>>>
>>>>>> The idea is nice, but ideas aren't enough. Where are the benchmarks
>>>>>> that show a
>>>>>> performance improvement over the C calling convention? And even if
>>>>>> such
>>>>>> improvement is present, is it worth it in the face of people that
>>>>>> don't want to
>>>>>> add it to GCC?
>>>>>
>>>>> GDC can certainly define its D calling convention to match GCC's. It's
>>>>> an "implementation defined" thing, not a language defined one.
>>>>>
>>>>
>>>> Then let's please rename it to the DMD ABI instead of calling it the D
>>>> ABI and making it look like it's part of the language on the website.
>>>> Further, D mangling rules should be separate from calling convention.
>>>>
>>>
>>> IIRC currently, the calling convention is mangled into the symbol name.
>>> Do you want to remove this?
>>
>> Not that I can see from http://dlang.org/abi.html ?
>>
>
> TypeFunction:
> CallConvention FuncAttrs Arguments ArgClose Type
>
> CallConvention:
> F // D
> U // C
> W // Windows
> V // Pascal
> R // C++
>

I see. I think it's a mistake to call that calling convention "D". I'm not against removing it, but the description is highly misleading.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 6/19/2012 4:23 PM, Manu wrote:
> That code could all be done with the register alias I described, and
> __push/__pop intrinsics.

Push/pop intrinsics won't work reliably, because on 16 byte aligned stack machines the compiler must emit stack alignment instructions at various points. With intrinsics, it won't know where to put the stack alignment.

On 20-06-2012 03:01, Walter Bright wrote:
> On 6/19/2012 3:47 PM, Alex Rønne Petersen wrote:
>> On 19-06-2012 23:52, Walter Bright wrote:
>>> GDC can certainly define its D calling convention to match GCC's. It's
>>> an "implementation defined" thing, not a language defined one.
>> Then let's please rename it to the DMD ABI instead of calling it the D
>> ABI
>> and
>> making it look like it's part of the language on the website.
>
> The ABI is not part of the language. For example, the C Standard says
> nothing whatsoever about the C ABI.

Then it's very misleading that it's under the language reference area of the website and calls it the "D ABI" and not the "DMD ABI". This might have been fine back when there was only DMD, but it really needs to be made clear that this is not an ABI that compilers are required to follow.

>
>> Further, D mangling rules should be separate from calling convention.
>
> I disagree. The mangling rules are not part of the language
> specification, either. But they are necessary so that a function with
> one convention won't be connected to one with another.
>

If compilers employed their own mangling schemes, debuggers and other tools would never be able to properly demangle names. I think it is important that the mangling is at least emphasized as a highly recommended (but not required) part of the language to implementors.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Tue, 19 Jun 2012, Walter Bright wrote:

> On 6/19/2012 3:47 PM, Alex R?nne Petersen wrote:
> > On 19-06-2012 23:52, Walter Bright wrote:
> > > GDC can certainly define its D calling convention to match GCC's. It's an "implementation defined" thing, not a language defined one.
> > Then let's please rename it to the DMD ABI instead of calling it the D ABI
> > and
> > making it look like it's part of the language on the website.
> 
> The ABI is not part of the language. For example, the C Standard says nothing whatsoever about the C ABI.
> 
> > Further, D mangling rules should be separate from calling convention.
> 
> I disagree. The mangling rules are not part of the language specification, either. But they are necessary so that a function with one convention won't be connected to one with another.

Let's not repeat the mistakes of c++, the mangling has got to be part of the language definition to facilitate interoperability between compilers. Similarily, the runtime's need to be interchangable.  Requiring the entire body of code to all come from the same compiler would be horrible.