dmd codegen improvements

[via Digitalmars-d]

On Thursday, 3 September 2015 at 02:30:41 UTC, Laeeth Isharc 
wrote:
> In my experience grumbling without action doesn't tend to lead 
> to the change you want in the world.  In theory maybe it 
> should, and someone will listen.  But human beings are funny 
> creatures.

End user back pressure helps. If it does not help, then the 
development process is FUBAR. However it does help, Walter is an 
intelligent man, that enjoys defending his position, but that 
does not mean that he does not listen to arguments and 
internalize them over time.

> Well how would a dictator of D accomplish that?  Probably 
> porting the compiler to D would be a pretty good start, for a 
> variety of reasons.  That will help with stability, 
> refactoring, and documentation I should have thought.  Not 
> everyone knows C++, and of those who do, not everyone wants to 
> write in it.

Dedicating one cycle to porting, another to refactoring and 
documentation is a very good start. IFF you focus on that and 
stick with it and avoid adding more features as code at the same 
time. (Add them to the plan/spec instead.)

> By the way, the dmd source code doesn't seem horribly obscure 
> to read at first glance.

Reading is one thing, making it do what you want another. For 
that you need either documentation or "reverse-engineering the 
underlying model".

> alors ?  as you point out, an asm.js backend would be rather 
> nice to have, and you are by all accounts a low-level guy, so 
> it shouldn't be hard to do, no ?

I don't have enough time to figure out all the ins-and-outs of 
the current compiler. To do that, in reasonable time, I would 
need a refactored and documented compiler. (I am also not 
primarily a low level person, my background is broad, but my 
major was in systems development).

> Given that C compilers are still developing, I doubt D will 
> ever be finished in my useful career.  So what ?  The facts 
> speak against your claim, since D is clearly becoming more 
> polished with every release - just look at the improvements to 
> the GC within the past year.  (Runtime/compiler, whatever).

Oh, I would love for D to follow the trajectory of C. C 
development can follow a near-waterfall development model:

1. specification-ratification-cycle
2. specification based gamma-beta-alpha production implementation
3. release
4. non-semantic improvements

D is nowhere near C's conservative fully spec'ed 
ISO-standard-based process.

Semantically C does not have many advantages over D, except VLAs 
(which I find rather useful and think D should adopt).

> Andrei talked about documentation and presentation a little 
> while back, and we're now in a much better state.  Allocators 
> soon here.

> People have got D to run on embedded systems with low resources.

What people can do isn't really all that interesting. What is 
interesting is what you can do with little effort and better than 
the alternatives. BASIC ran on machines with just a few K's of 
RAM, that does not make it a reasonable choice.

> enough for my modest needs.  I'd honestly bet that a little 
> more effort to communicate the practical commercial benefits of 
> D would make much more of a difference than this abstract 
> stuff.  But who am I to say.

I think you underestimate the expections people with a major in 
compsci or a significant amount of development experience have. 
They care about the actual qualities, not the presentation. Those 
are the CTOs you need to convince, not the CEOs.

As it stands today both Rust and D falls into the category 
toy-languages. "toy language" is the term academics use to 
describe their languages that explore interesting ideas, but does 
not have the polish, tooling or commercial backing to take a 
significant market share.