Migrating dmd to D?

David Nadlinger see at klickverbot.at
Mon Mar 4 10:58:27 PST 2013


On Thursday, 28 February 2013 at 15:24:07 UTC, Andrei 
Alexandrescu wrote:
> On 2/28/13 5:03 AM, deadalnix wrote:
>> That will impair GDC and LDC quite a lot.
>
> Let's see what the respective project leaders say.

Well, let me first emphasize that I agree that having the D 
reference implementation written in D is a desirable goal for a 
number of reasons, such as outlined by Andrei in his initial 
post. I am not sure whether using DMD as a basis is the ideal 
approach as far as the ultimate outcome is concerned, but it 
certainly has its merits considering the limited time budget.

That being said, moving parts of the front-end source to D will 
in any case cause quite a bit of minor work all over the place 
for LDC (porting LDC-specific changes, adapting the build system, 
...), and I would be glad if somebody new could take this as an 
opportunity to join LDC development, as the time that Kai and I 
(the current main contributors) can spend on LDC right now is 
unfortunately rather limited anyway.

Apart from such minor effects, I only really see two possible 
issues to be aware of:

First, requiring a D compiler to build LDC will make life harder 
for people preparing distribution packages, at least for packages 
in the actual upstream repositories where the packages usually 
have to be buildable from source (with dependencies also being 
met out of the distro's repositories). This is not at all an 
unsolvable issue, but the migration should be coordinated with 
the packaging crowd to ensure a smooth transition.

In this regard, we should also make sure that the front-end (and 
thus GDC and LDC) can be bootstrapped of a Free/OSS D compiler, 
otherwise integration of GDC/LDC into Debian, Fedora, ... might 
become a problem. Not that this should be a huge issue with GDC 
and LDC being around, but I thought I would mention it.

Second, rewriting all of *LDC's* code in D would be a huge task, 
as the use of C++ templates is pervasive through the LLVM C++ API 
(even if they are used pretty judiciously), and the LLVM C API is 
a lot less powerful in some aspects. Thus, care should be taken 
that the D frontend can actually be used with some of the virtual 
method implementations still in C++ (e.g. toElem/toElemDtor and 
similar LDC-specific ones).

Your (Andrei's) initial post sounded like this would be the case. 
But if I interpreted some of the posts correctly, Daniel Murphy 
has an automatic translator in the works for porting over the 
whole compiler (except for the backend) at once, which might be a 
problem for LDC.

David


More information about the Digitalmars-d mailing list