On 12/16/2020 2:33 AM, Max Haughton wrote:
> I know I just like the dmd-style ones, it feels much more ergonomic than the equivalent in C++. I'm not a huge fan of GCC style asm, but ultimately I guess I'm bikeshedding.

The dmd-style ones hearken back to the good ole DOS days, where MASM matched the Intel documentation. It's an evolved version of the inline assembler used by Digital Mars C, which matches MASM and Intel.

Intel has kept the same syntax ever since, and DMD's inline asm has kept on matching it.

The same syntax is generated by obj2asm.

If DMD ever did an ARM back end, the syntax would match the official ARM vendor's CPU documentation.

On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright wrote:
> On 12/14/2020 1:57 AM, Abdulhaq wrote:
>> DMD is Walter's baby and he's going to continue with that, having power over it is secondary to that.
>> 
>> D Foundation of course want to retain control over what they have built, it's years and years of their hard work, decades even. Why should they give control to someone else and why think that that other group would do any better? Arguably it would be irresponsible to do that.
>
>
> Having DMD means we can support whatever target we want to, we are not constrained by a community we don't really have a voice in.

That's a specious argument.

"Having DMD means we can add whatever optimisations we want to, we arnt constrained by a community we dont really have a voice in."

And yet why does DMD suck at optimising code? Because a freedom to do something that nobody has the resources to do is next to useless.

And lets be honest if LLVM doesnt support it, it's pretty small potatoes, who's going to go to that kind of effort to add some niche architecture to DMD?

On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:
> On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright wrote:
>> On 12/14/2020 1:57 AM, Abdulhaq wrote:
>>> [...]
>>
>>
>> Having DMD means we can support whatever target we want to, we are not constrained by a community we don't really have a voice in.
>
> That's a specious argument.
>
> "Having DMD means we can add whatever optimisations we want to, we arnt constrained by a community we dont really have a voice in."
>
> And yet why does DMD suck at optimising code? Because a freedom to do something that nobody has the resources to do is next to useless.
>
> And lets be honest if LLVM doesnt support it, it's pretty small potatoes, who's going to go to that kind of effort to add some niche architecture to DMD?

LLVM still doesn't support plenty of embedded targets that GCC does.

Small potatoes like million of 8 and 16 bit devices sold per year.

On Thursday, 17 December 2020 at 10:34:33 UTC, Paulo Pinto wrote:
> On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:
>> On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright wrote:
>>> [...]
>>
>> That's a specious argument.
>>
>> "Having DMD means we can add whatever optimisations we want to, we arnt constrained by a community we dont really have a voice in."
>>
>> And yet why does DMD suck at optimising code? Because a freedom to do something that nobody has the resources to do is next to useless.
>>
>> And lets be honest if LLVM doesnt support it, it's pretty small potatoes, who's going to go to that kind of effort to add some niche architecture to DMD?
>
> LLVM still doesn't support plenty of embedded targets that GCC does.
>
> Small potatoes like million of 8 and 16 bit devices sold per year.

The point is to have a master/default compiler that supports the main notebook/PC CPU architectures. LLVM and GCC are equal there.

On Thursday, 17 December 2020 at 10:34:33 UTC, Paulo Pinto wrote:
> On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:
>> On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright wrote:
>>> On 12/14/2020 1:57 AM, Abdulhaq wrote:
>>>> [...]
>>>
>>>
>>> Having DMD means we can support whatever target we want to, we are not constrained by a community we don't really have a voice in.
>>
>> That's a specious argument.
>>
>> "Having DMD means we can add whatever optimisations we want to, we arnt constrained by a community we dont really have a voice in."
>>
>> And yet why does DMD suck at optimising code? Because a freedom to do something that nobody has the resources to do is next to useless.
>>
>> And lets be honest if LLVM doesnt support it, it's pretty small potatoes, who's going to go to that kind of effort to add some niche architecture to DMD?
>
> LLVM still doesn't support plenty of embedded targets that GCC does.
>
> Small potatoes like million of 8 and 16 bit devices sold per year.

There are probably more ARM chips sold than anything else, DMD doesnt support them, so the idea that it will support these 8 and 16 bit micro controllers is ludicrous.

So in spite of what you say my point still stands. Arguing that DMD gives us a freedom to target whatever architecture we want is specious.

With enough effort I can fly to the moon, except that I cant.

On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:
>
> And yet why does DMD suck at optimising code? Because a freedom to do something that nobody has the resources to do is next to useless.

DMD builds fast, and is small, it has some value and it would be more used if you could somehow rely on code generation. (for example, raylib ships with a tinycc compiler for speed of compile-run loop)

However I think an ARM backend may be just too much debt when we don't have a reliable x86 backend in DMD. And I don't know why it's the case, it has been a constant over years.

(for info: the particular issue that irks me is https://issues.dlang.org/show_bug.cgi?id=21474)

I'd be really wary to release something built with DMD and optimizations on.
This is not _only_ about speed imho.

On Thursday, 17 December 2020 at 16:02:05 UTC, Guillaume Piolat wrote:
> On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:
>>
>> And yet why does DMD suck at optimising code? Because a freedom to do something that nobody has the resources to do is next to useless.
>
> DMD builds fast, and is small, it has some value and it would be more used if you could somehow rely on code generation. (for example, raylib ships with a tinycc compiler for speed of compile-run loop)

Oh yeah I agree, it's clear a lot of people value DMDs fast compile times. I remember using Delphi years and years ago, and it was like 1 second compile, every time. It was so fast it took no more time to recompile and let it go to the first error, than it did to locate it yourself. There's definite value in that.


> However I think an ARM backend may be just too much debt when we don't have a reliable x86 backend in DMD. And I don't know why it's the case, it has been a constant over years.
>
> (for info: the particular issue that irks me is https://issues.dlang.org/show_bug.cgi?id=21474)
>
> I'd be really wary to release something built with DMD and optimizations on.
> This is not _only_ about speed imho.

Yeah, thats not good.

On Thu, Dec 17, 2020 at 04:02:05PM +0000, Guillaume Piolat via Digitalmars-d wrote: [...]
> However I think an ARM backend may be just too much debt when we don't have a reliable x86 backend in DMD. And I don't know why it's the case, it has been a constant over years.
> 
> (for info: the particular issue that irks me is
> https://issues.dlang.org/show_bug.cgi?id=21474)
> 
> I'd be really wary to release something built with DMD and optimizations on.  This is not _only_ about speed imho.

See, it's bugs like these that eventually convinced me no longer to use DMD for production builds.  For development or small projects where speed is not important, DMD fine, I just don't use -O or -inline; DMD compiles lightning fast compared to the other compilers, it's lightweight and easy to install and run, it's even easy to build (I build DMD from git master), and really boosts your code-compile-test cycle.

For production builds of non-trivial projects, though, I can't depend on it. Over the years I've run into codegen bugs, usually triggered by -O, -inline, or both. Which unfortunately exacerbates the already well-known suboptimal output.  Plus cross-compilation is not supported right now. LDC gives me reliable codegen, very good optimizations, and built-in cross-compilation.  Plus good CPU targeting, which in some applications make a big difference (e.g., issuing POPCOUNT instructions on CPUs that support it, can really boost certain algorithms).  And LDC has been tracking DMD releases very closely since a year or two ago, so it's not lacking in the new features department either.  Overall, LDC works much better for me in the production department.  In this area DMD isn't even on my radar anymore.


T

-- 
Не дорог подарок, дорога любовь.

On Thursday, 17 December 2020 at 16:02:05 UTC, Guillaume Piolat wrote:
> I'd be really wary to release something built with DMD and optimizations on.

My view is the -O, -inline, and -release switches should all become no-ops in dmd. They're slow and dangerous. I already advise people to never use them* and they weaken dmd rather than strengthen it.

* There is one exception: building druntime. It actually makes a difference there and since it is fairly better controlled it actually can use them and since druntime it not fully compatible across compilers you can't really mix and match. But that's it.

On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright wrote:

>
> I don't see how LDC and GDC are impaired in any way by DMD.

I feel having a compiler like dmd that takes seconds to build is great.

However there is a huge price ... your time !