View mode: basic / threaded / horizontal-split · Log in · Help
June 19, 2012
Re: GDC review process.
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
June 19, 2012
Re: GDC review process.
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
June 19, 2012
Re: GDC review process.
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?
June 19, 2012
Re: GDC review process.
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.
June 19, 2012
Re: GDC review process.
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.
June 19, 2012
Re: GDC review process.
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
June 19, 2012
Re: GDC review process.
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?
June 19, 2012
Re: GDC review process.
> 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?
June 19, 2012
Re: GDC review process.
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.
June 19, 2012
Re: GDC review process.
> Plus, gcc asm syntax is horrible, and DMD's is really nice.

yep, AT&T vs. Intel syntax :)
1 2 3 4 5 6
Top | Discussion index | About this forum | D home