xdc: A hypothetical D cross-compiler and AST manipulation tool.

[Chad Joan]

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.