View mode: basic / threaded / horizontal-split · Log in · Help
June 19, 2012
Re: GDC review process.
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?
June 20, 2012
Re: GDC review process.
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
June 20, 2012
Re: GDC review process.
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
June 20, 2012
Re: GDC review process.
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.
June 20, 2012
Re: GDC review process.
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++
June 20, 2012
Re: GDC review process.
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.
June 20, 2012
Re: GDC review process.
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
June 20, 2012
Re: GDC review process.
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.
June 20, 2012
Re: GDC review process.
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
June 20, 2012
Re: GDC review process.
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.
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home