Alex Rønne Petersen:

> Because the guest wants to rearrange the host's home.
>
> D better have a good reason to do so. So far, I have seen none.

Lot of time ago I have suggested to Walter to look at the D design searching for features that are hard to implement on normal back-ends (at that time I was helping a bit the development of LDC), and reconsider them. So I agree asking for useless changes in a host's home is bad.

On the other hand introducing one more calling convention is an additive change for GCC, so it's not a rearrangement.

I have used inline asm many times in DMD, as I have used it many times in Delphi, I like a lot.

This is mostly a technical discussion, but I don't expect all Walter opinions to be the same as the opinions of GCC designers.
Generally GDC should try to be as close to the D specs as possible :-)

Bye,
bearophile

On 19-06-2012 21:17, bearophile wrote:
> Alex Rønne Petersen:
>
>> Because the guest wants to rearrange the host's home.
>>
>> D better have a good reason to do so. So far, I have seen none.
>
> Lot of time ago I have suggested to Walter to look at the D design
> searching for features that are hard to implement on normal back-ends
> (at that time I was helping a bit the development of LDC), and
> reconsider them. So I agree asking for useless changes in a host's home
> is bad.
>
> On the other hand introducing one more calling convention is an additive
> change for GCC, so it's not a rearrangement.
>
> I have used inline asm many times in DMD, as I have used it many times
> in Delphi, I like a lot.

Just to make it clear: GDC still has GCC-style inline assembly.

>
> This is mostly a technical discussion, but I don't expect all Walter
> opinions to be the same as the opinions of GCC designers.
> Generally GDC should try to be as close to the D specs as possible :-)
>
> Bye,
> bearophile

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

On 6/19/2012 11:19 AM, Iain Buclaw wrote:
> 1) D Inline Asm and naked function support is raising far too many alarm bells.
> So would just be easier to remove it and avoid all the other comments on why we
> need middle-end and backend headers in gdc.

I'm not clear on why the inline assembler is a problem?

On 6/19/2012 11:57 AM, Iain Buclaw wrote:
> To quote from one of the i386 backend maintainers:
> ---
> "Does D *really* require a new calling convention?

No, but the idea was to allow D to innovate on calling conventions without disturbing code that needed to interface with C.

> Also does it *really* require naked support?
> I think naked support is a bad idea
> and people who require naked support should be writing an assembly
> function wrapper."
> ---

Naked support allows people to write max efficient assembler without needing to exit the language and use the (often miserable) standalone assembler.

On Tuesday, 19 June 2012 at 20:04:12 UTC, Walter Bright wrote:
> On 6/19/2012 11:57 AM, Iain Buclaw wrote:
>> To quote from one of the i386 backend maintainers:
>> ---
>> "Does D *really* require a new calling convention?
>
> No, but the idea was to allow D to innovate on calling conventions without disturbing code that needed to interface with C.
>
>> Also does it *really* require naked support?
>> I think naked support is a bad idea
>> and people who require naked support should be writing an assembly
>> function wrapper."
>> ---
>
> Naked support allows people to write max efficient assembler without needing to exit the language and use the (often miserable) standalone assembler.

From what I gathered from further discussion, it made sense for embedded platforms, such as ARM, but not x86.

Iain Buclaw:

> From what I gathered from further discussion, it made sense for embedded platforms, such as ARM, but not x86.

Why?

If this whole discussion wants to go somewhere, and not just be a waste of everyone time like similar past discussions on such topics, it needs a *much larger* amount of technical arguments, both pro and against the various positions.

This discussion also requires people that work on LDC, to see their problems.

If I write inline asm code on DMD I'd really like the code to compile on GDC too, on the same CPU and OS.

----------------------

Walter:

> 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?

Bye,
bearophile

On 19 June 2012 21:19, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> 1) D Inline Asm and naked function support is raising far too many alarm bells. So would just be easier to remove it and avoid all the other comments on why we need middle-end and backend headers in gdc.
>

Inline assembly has been relatively useless in GCC for years. Inline asm
interferes with the optimisers ability to do a good job, which basically
makes use of inline assembly self-defeating.
The only time I ever need to use inline-asm is to interface an arch feature
that has no API. As long as there are intrinsics for all the opcodes one
might want, then it's better to use them.

There are 2 operations that spring to mind that typically don't have intrinsics, or high level API's, which I always use asm to interface; the fine-grain manual manipulation of the flags register on PPC (ie, the '.' suite of opcodes), and conditional execution opcodes on ARM. Neither of these have high level expressions, and they are both relatively important. That said, as stated above, if use of this stuff is for performance, then using an inline-asm block will ruin the surrounding code anyway, so I almost always find I'm required to write the entire function in asm to achieve the expected result...

I see no major loss to removing the inline assembler.
I would like to know what the issue is though? Why are you compelled to
remove it?
I thought GCC optionally supported the microsoft asm syntax instead, which
should make it syntactically consistent with D?

> 1) D Inline Asm and naked function support is raising far too many alarm bells. So would just be easier to remove it and avoid all the other comments on why we need middle-end and backend headers in gdc.

And the C++ frontend doesn't need these headers for its inline assembler implementation?

Le 19/06/2012 20:51, Alex Rønne Petersen a écrit :
> On 19-06-2012 20:44, bearophile wrote:
>> Iain Buclaw:
>>
>>> Most discussion I would imagine be on the decision to remove D inline
>>> assembler support from gdc. So, nay sayers, do your worst, but
>>> unfortunately there is a +1 here for removal.
>>
>> I suggest to try to do the opposite, that it to try to increase
>> the current conformance of GDC to D/DMD specs (like introducing D
>> calling conventions, if they are missing).
>>
>> Bye,
>> bearophile
>
> Not gonna happen. The D calling convention is Windows/32-bit only.
> Implementing a new calling convention in all major compiler back ends is
> not something you do trivially. Further, I doubt the GCC maintainers
> would actually approve of doing this.
>

frankly, we don't care. 32bits windows is not the plateform of the future.

GDC and DMD have consistent ABI on all other plateforms. This allow to write code that compile both with DMD and GDC on most plateform.

This make no sense to drop D asm support. This is not because the situation is b0rken on window 32 bits that we should break it on all other plateforms.

The asm syntax should be DMD compliant on x86 and x86_64.

Plus, gcc asm syntax is horrible, and DMD's is really nice.

> Plus, gcc asm syntax is horrible, and DMD's is really nice.

yep, AT&T vs. Intel syntax :)