Community

[also posted to D.gnu]
Hi, folks,
I'm interested in creating a D front end for GCC that would be part of the GCC codebase. My feeling is that a GDC that is part of GCC distributions will likely have more life than one that must be updated whenever a new GCC release comes out. As with linux kernel in-tree drivers being kept up to date, an integrated GDC would tend to move forward as well.
To do this though, copyright on the code must be assigned to the FSF. This means that even though the DMD front end sources are licensed under the GPL, they cannot be directly used to write this front end as the copyright is owned by DigitalMars. Everyone who contributes code must not look at the DMD compiler source code to avoid accidentally contributing code illegally. Therefore, this will be a completely new implementation of D.
The obvious disadvantage of doing this is that it will be a slow process to get to a working D compiler. However, one advantage to the D world is firming up and validating the language specification so that the language is not defined by what the DMD compiler does.
My personal desire is to implement (and track) the 2.0 language since I would like to see that feature set available through GCC. Second, by the time a working front end becomes part of GCC, the 2.0 language will likely be complete.
One question I have (of many) is whether a different name should be used. If this is called GDC there will be some confusion with the current GDC. What thoughts do you all have?
In general is there interest in this project, especially contributing to it?
Thanks,
Jerry

Jerry Quinn wrote:
> My personal desire is to implement (and track) the 2.0 language since
> I would like to see that feature set available through GCC. Second,
> by the time a working front end becomes part of GCC, the 2.0 language
> will likely be complete.
>
> One question I have (of many) is whether a different name should be
> used. If this is called GDC there will be some confusion with the
> current GDC. What thoughts do you all have?
>
> In general is there interest in this project, especially contributing
> to it?
Obviously, I can't help you with a clean room reimplementation, but I do
wish you every success with the project. I can also help with
specification problems that will inevitably arise.

Jerry Quinn:
> I'm interested in creating a D front end for GCC that would be part of the GCC codebase.
What about helping LDC devs create a good D2 implementation instead? It's probably 1/5 or 1/10 of the work you think about, because lot of work is already done, and surely some people will help you (me too).
There's Dil, DMD, GDC, LDC, D#, etc, but one good, debugged and well optimizing fully open source D2 compiler is much better than ten broken and/or badly optimizing D compilers.
Bye,
bearophile

> What about helping LDC devs create a good D2 implementation instead?
> It's probably 1/5 or 1/10 of the work you think about, because lot of
> work is already done, and surely some people will help you (me too).
>
Is D2 support being worked on at all?

On 01/18/2010 03:45 AM, Jerry Quinn wrote:
> [also posted to D.gnu]
>
> Hi, folks,
>
> I'm interested in creating a D front end for GCC that would be part of the GCC codebase. My feeling is that a GDC that is part of GCC distributions will likely have more life than one that must be updated whenever a new GCC release comes out. As with linux kernel in-tree drivers being kept up to date, an integrated GDC would tend to move forward as well.
>
> To do this though, copyright on the code must be assigned to the FSF. This means that even though the DMD front end sources are licensed under the GPL, they cannot be directly used to write this front end as the copyright is owned by DigitalMars. Everyone who contributes code must not look at the DMD compiler source code to avoid accidentally contributing code illegally. Therefore, this will be a completely new implementation of D.
>
> The obvious disadvantage of doing this is that it will be a slow process to get to a working D compiler. However, one advantage to the D world is firming up and validating the language specification so that the language is not defined by what the DMD compiler does.
>
> My personal desire is to implement (and track) the 2.0 language since I would like to see that feature set available through GCC. Second, by the time a working front end becomes part of GCC, the 2.0 language will likely be complete.
>
> One question I have (of many) is whether a different name should be used. If this is called GDC there will be some confusion with the current GDC. What thoughts do you all have?
>
> In general is there interest in this project, especially contributing to it?
>
> Thanks,
> Jerry
>
I do not want to discourage such a great project, especially since I
lack the skills myself to contribute. However I think helping either GDC
or LDC with their D2 branches and getting them into a distro will be far
more effective. Whatever you decide to embark on, wish you all the best!

bearophile Wrote:
> Jerry Quinn:
> > I'm interested in creating a D front end for GCC that would be part of the GCC codebase.
>
> What about helping LDC devs create a good D2 implementation instead? It's probably 1/5 or 1/10 of the work you think about, because lot of work is already done, and surely some people will help you (me too).
>
> There's Dil, DMD, GDC, LDC, D#, etc, but one good, debugged and well optimizing fully open source D2 compiler is much better than ten broken and/or badly optimizing D compilers.
>
> Bye,
> bearophile
I agree that having such a good intent the author of the post should better concentrate his effort on helping GDC/LDC. LDC took couple of years to become usable, and you have to consider that they took an existing front-end.
Also what I think even when you complete this project, it is not only the licensing issues that are preventing GDC from being included into GCC. They will do that only if they are interested in this project, as it requires maintenance. They will not update GCC-D frontend with every release of GCC just because it is a part of it.
Having a solid GDC implementation you can be sure that it will be included in distributions (Debian had GDC for quite a long time).

"Eldar Insafutdinov" <e.insafutdinov@gmail.com> wrote in message
news:hj2njd$o1g$1@digitalmars.com...
>
> Having a solid GDC implementation you can be sure that it will be included
> in distributions (Debian had GDC for quite a long time).
"had"? Is that a typo or did they drop it?

Eldar Insafutdinov Wrote:
> bearophile Wrote:
>
> > Jerry Quinn:
> > > I'm interested in creating a D front end for GCC that would be part of the GCC codebase.
> >
> > What about helping LDC devs create a good D2 implementation instead? It's probably 1/5 or 1/10 of the work you think about, because lot of work is already done, and surely some people will help you (me too).
One reason is that I'm already positioned to contribute code to GCC. and it is more difficult for me to become an LDC dev. ANother is that GCC has very broad backend support. I know LLVM backend support is expanding but it still has some distance to go. GCC is also the default compiler for many Linux distributions, and D be part of that may help it propagate.
I also do think that the construction of another front end would provide positive benefit to the D community by improving the language specification and separating it from implementation. Of course that's only true if this succeeds :-)
There's also a benefit to the GCC project in terms of improving the docs on the frontend interface. That's already happened as I've tried to figure out how it works :-) But that's not so relevant to the folks here.
> > There's Dil, DMD, GDC, LDC, D#, etc, but one good, debugged and well optimizing fully open source D2 compiler is much better than ten broken and/or badly optimizing D compilers.
> >
> > Bye,
> > bearophile
>
> I agree that having such a good intent the author of the post should better concentrate his effort on helping GDC/LDC. LDC took couple of years to become usable, and you have to consider that they took an existing front-end.
>
> Also what I think even when you complete this project, it is not only the licensing issues that are preventing GDC from being included into GCC. They will do that only if they are interested in this project, as it requires maintenance. They will not update GCC-D frontend with every release of GCC just because it is a part of it.
This is very true. It would require people to be interested in continuing it's existence.
> Having a solid GDC implementation you can be sure that it will be included in distributions (Debian had GDC for quite a long time).
In my mind, the endgame for GDC would be to have the work integrated into the official GCC sources. That would provide the similar benefits to the ones I'm chasing. Everyone who touched GDC would have to assign their code to the FSF and the DMD sources would also have to be assigned. Perhaps that's the right answer in the end but I don't know. It does seem to be a substantial effort to make that happen.
Jerry

Nick Sabalausky wrote:
> "Eldar Insafutdinov" <e.insafutdinov@gmail.com> wrote in message
> news:hj2njd$o1g$1@digitalmars.com...
>>
>> Having a solid GDC implementation you can be sure that it will be included
>> in distributions (Debian had GDC for quite a long time).
>
> "had"? Is that a typo or did they drop it?
>
They have it still, v 0.25 for GCC 4.1 (if I interpreted those right)