State of the Compiler
Walter Bright via Digitalmars-d
digitalmars-d at puremagic.com
Sun Feb 28 16:10:33 PST 2016
I'm pretty unhappy with the state of dmd. I think the best that can be said for
it at the moment is that it works.
1. every time we fix something, there are unexpected regressions.
2. the code is a hopeless tangle.
3. too much global state (like global.errors, which is itself a source of
repeated regressions)
4. it's slowed down substantially.
5. near complete lack of encapsulation
6. my ideas on how software should be written have evolved a lot since it was
laid out
This cannot be fixed overnight, but I've been working on it off and on in
between doing other more urgent things, and submitting PRs for them. The goals
of all this are (and this includes the back end):
1. elimination of all conditional compilation, and macros. All that code should
be encapsulated and banished to Port or Target.
2. encapsulation of all memory management. For example, StringExp's instance of
string data is allocated and free'd all over the place. I've made some progress
in encapsulating it. Getting it properly encapsulated means we can do Small
String Optimization in it, which should get us a nice boost. SSO for all these
sorts of structures needs to be done.
3. retrofit in const as much as possible, and later try to use pure.
4. get rid of all global state variables, except for configuration stuff set by
command line switches
5. convert back end to D.
6. use nested functions to improve encapsulation.
7. remove C++ artifacts, like the fake delegates, and replace them with real
delegates
8. replace symbol tables and custom hash code with builtin hashes, and fix the
builtin hashes if they aren't as fast
9. change to "full lazy" semantic analysis of imports, i.e. only parse them far
enough to build the symbol table. Do semantic analysis of the symbols only on
demand. I did this for enums a while back, and the results have been very pleasing.
10. use rc memory for CTFE, or even stack memory. this is already done to a
small extent, but should go much further
11. encapsulate, encapsulate, encapsulate
12. start retrofitting with phobos algorithms
13. use ranges
One benefit of all this is we could start using multicores to compile!
This will all take years, but we've already made good progress such as the
conversion of the source code to D.
More information about the Digitalmars-d
mailing list