On Sunday, 10 November 2013 at 08:21:37 UTC, Walter Bright wrote:
On 11/9/2013 9:27 PM, deadalnix wrote:
On Sunday, 10 November 2013 at 04:54:18 UTC, Daniel Murphy
wrote:
That is true in general, but D actually maps quite well onto
C.
I did some work on creating a C backend a while back, and it
worked quite
well.
Out of curiosity, how do you handle exceptions ?
Exceptions is one big problem. Another is COMDATs - C compilers
don't emit them. COMDATs are needed to support templates (they
remove duplicate instances).
And TLS.
This seems like it matters when linking D code to D code. Other
language's wouldn't care about D's templates. I imagine that in
most cases it would be possible to just compile the D code
together.
This whole mess can be done away with by removing the "linking"
step in compilation, which is what I'd recommend for a compiler
that is designed to output things that aren't object files.
The compiler should be able to dedup templates internally when
doing AST manipulation. I actually /expect/ this.
The only reasons to output object files, that I can think of
right now, are as follows:
- Obfuscation is desired in the output.
- Incremental compiling.
To meet those needs, the following approaches could be used:
- Obfuscation: A compiler without a linkable output format could
support an "obfuscation" target that would output obfuscated D
code for later compiling in a 3rd party's hands.
- Incremental Compiling: This is usually done to help with
terrible build times. A compiler without a linkable output
format could offer a "do as much as you can" target that outputs
D code that is lowered as far as it can possibly be lowered
without being fed more information. At that point, D might be
nearly as fast as the linker, at least in human terms.
