Ready for review: new std.uni

Walter Bright newshound2 at digitalmars.com
Sun Jan 13 15:57:48 PST 2013


On 1/13/2013 3:10 PM, David Nadlinger wrote:
> To elaborate – and again, please don't take this as a personal attack –, every
> time this discussion comes up you seem to resort to the »diversity is good«
> cliché

Being a cliche doesn't make it invalid.

> without ever actually responding to the arguments other people bring up.
> You want to stick to the DMC backend? Fine, that's your good right, but wouldn't
> it only be fair to share your reasons with the other people who are investing
> considerable amounts of work and time in »your« language?

It's long ceased to be my language. It's a group creation.

Anyhow, I like using the dmc backend because:

1. I can completely control the user experience.

2. I can fix a problem where it should be fixed, rather than working around it.

3. I understand it completely, and so I can reasonably quickly add in things 
that some other back end may not support.

4. It's fast.

5. I don't run any risk of "you stole X's ideas when you worked on X's back end."

6. I enjoy working on it.


> So, in short, even if the DMC backend was technically superior to every other
> solution out there right now, I would be hard-pressed to make an argument for
> preferring it over a more widely used solution like LLVM because of this. I
> cannot see how putting work into a custom backend could realistically help to
> make D more attractive compared to other languages, so the current situation
> seems like a case of making things unnecessarily hard for ourselves.

This assumes that the existence of dmd takes away from ldc. I don't believe it 
does. Ldc doesn't need me.

> To summarize: Although there is quite a lot of promising development going on in
> the language space right now, I still think D has an excellent offer to make,
> otherwise I would left the camp long ago. But it doesn't seem wise to
> intentionally weaken our position in the arena by spending considerable amounts
> of manpower on solving a problem from the ground up for which there is already a
> free off-the-shelf solution that would get us at least 95% there – and the fact
> that our resources are limited is precisely what you seem to neglect when
> reciting the »diversity is good« mantra.

I'm not convinced that the effort to keep up with llvm in order to work with it 
is actually less time.


>> For example, LDC doesn't work with VS, and so would have cost
>> us the possible design win at Remedy.
>
> In view of the above, I'm not sure how much weight this argument could carry,
> but I don't think it is valid in the first place: If our reference compiler was
> backed by LLVM, you could have just added CV8 support to it like you did for
> DMD.

The thing is, I don't see how that would have saved time. It would have been 
more time - I already had CV4 support in dmd, so I had a head start on CV8. 
There were also a number of wacky things about Mscoff64 - how to integrate them 
into LLVM would have required a thorough knowledge of it on my part, and *then* 
I'd still have to implement it. There were also the MS64 ABI changes, which 
consumed a considerable amount of time. If that is not in LLVM, I would have 
been in for a world of effort and would have had to do some considerable surgery 
on it.

> By the way, the other thing missing from LLVM regarding VS compatibility is
> SEH support, but DMD doesn't implement that either (LLVM actually supports EH on
> MinGW right now, so the implementation could likely have been re-used as a
> workaround, just like you did for DMD).

I think that underestimates what all is necessary to be ABI and format 
compatible with VC64. SEH is only a small part of it. For example,

1. Win64 ABI, which is fundamentally different from any other platform
2. Making it compatible with and use VC++'s runtime
3. Generating MsCoff 64.
4. Adding the wacky pdata and xdata sections
5. Learning the completely undocumented CV8 format, then implementing it

Doing this all requires a fairly comprehensive understanding of the innards of 
the back end. If LLVM is lacking one or more of 1..5, then I wouldn't be 
surprised a bit if it took me considerably *longer* to do it for LLVM, and then 
I'd have to sell my changes to the LLVM group. (If they don't buy it, then I'm 
stuck with a fork I have to maintain myself. Ugh.)



More information about the Digitalmars-d mailing list