What is the long-term plan for the current DMD backend? I've noticed the first steps towards 64-bit support were just checked in today (excitement to the extreme). However, the backend is under such a restrictive license (which I understand Walter is not free to change) that it has a "bus factor" of 1. If Walter were to stop maintaining it, noone else would be able to, if I understand the licensing issues correctly.
Is there a chance of these licensing issues being cleared up so that the backend can be released under a more permissive license? If not, while I understand Walter's decision to use a backend he was familiar with in the beginning, it seems like we should abandon such a heavily encumbered backend now that it needs serious work.

dsimcha <dsimcha@yahoo.com> wrote:
> What is the long-term plan for the current DMD backend? I've noticed
> the
> first steps towards 64-bit support were just checked in today
> (excitement to
> the extreme). However, the backend is under such a restrictive
> license (which
> I understand Walter is not free to change) that it has a "bus factor"
> of 1.
> If Walter were to stop maintaining it, noone else would be able to, if
> I
> understand the licensing issues correctly.
> > Is there a chance of these licensing issues being cleared up so that
> the
> backend can be released under a more permissive license? If not,
> while I
> understand Walter's decision to use a backend he was familiar with in
> the
> beginning, it seems like we should abandon such a heavily encumbered
> backend
> now that it needs serious work.
I think it makes complete sense for the DigitalMars D compiler to use the DigitalMars backend. What we really need is more community work on compilers using other backends (GDC, LLVMDC) as well. The language can only benefit from having more than one compiler available.

== Quote from dsimcha (dsimcha@yahoo.com)'s article
> What is the long-term plan for the current DMD backend? I've noticed the
> first steps towards 64-bit support were just checked in today (excitement to
> the extreme). However, the backend is under such a restrictive license (which
> I understand Walter is not free to change) that it has a "bus factor" of 1.
> If Walter were to stop maintaining it, noone else would be able to, if I
> understand the licensing issues correctly.
> Is there a chance of these licensing issues being cleared up so that the
> backend can be released under a more permissive license? If not, while I
> understand Walter's decision to use a backend he was familiar with in the
> beginning, it seems like we should abandon such a heavily encumbered backend
> now that it needs serious work.
Hi
I agree with what Sean says. Even more, DMD backend is good for development process, because it is very fast as opposed to more popular ones like llvm or gcc. What really worries me is what is going to happen on Windows. We have the burden which is old file format and optlink. There are still big problems with the linker, it has random problems on big projects, building them with debug info is even more problematic. As far as I understood that linker is being rewritten to C, but the process is very slow. It may take years to complete the port, and then to make it 64bit capable, isn't it? All existing problems would be propagated further. I would suggest(again and again) to add a new Windows backend targeting MinGW or MSVC toolchain. It should not necessarily replace the existing one, but people would at least have freedom and there wouldn't be situation that you are stuck in development when linker fails. Also those toolchain support 64bit, so it is another advantage. For those who still wants digital mars toolchain - there will be an old one. Remembering that it took Walter about 6 weeks to implement MacOS backend, that doesn't seem too bad. In the end, Windows is the most popular OS despite our personal preferences, and it's worth spending some time for it.
Cheers

"Eldar Insafutdinov" <e.insafutdinov@gmail.com> wrote in message news:hvo49k$1uk3$1@digitalmars.com...>> In the end, Windows is the most popular
> OS despite our personal preferences, and it's worth spending some time for
> it.
>
I wish someone could convince LLVM of that...

On 21/06/10 16:07, dsimcha wrote:
> What is the long-term plan for the current DMD backend? I've noticed the
> first steps towards 64-bit support were just checked in today (excitement to
> the extreme). However, the backend is under such a restrictive license (which
> I understand Walter is not free to change) that it has a "bus factor" of 1.
> If Walter were to stop maintaining it, noone else would be able to, if I
> understand the licensing issues correctly.
>> Is there a chance of these licensing issues being cleared up so that the
> backend can be released under a more permissive license? If not, while I
> understand Walter's decision to use a backend he was familiar with in the
> beginning, it seems like we should abandon such a heavily encumbered backend
> now that it needs serious work.
Perhaps the 64bit backend could be written in such a way that it doesn't have the licensing issues? I have no idea what the specifics are to say if this is possible, it'd be good to not have the 64 bit backend under the current backend license though.

In windows if you want use some lib that is not provide dynamic dll support, you need compile it with dmc. In this case your need deal a lot problem with lack of c head file . if there is a vc++ version backend will be big help for a lot of people who is not familiarity with c/c++ .
2010/6/22 Eldar Insafutdinov <e.insafutdinov@gmail.com>
> == Quote from dsimcha (dsimcha@yahoo.com)'s article
> > What is the long-term plan for the current DMD backend? I've noticed the first steps towards 64-bit support were just checked in today (excitement
> to
> > the extreme). However, the backend is under such a restrictive license
> (which
> > I understand Walter is not free to change) that it has a "bus factor" of
> 1.
> > If Walter were to stop maintaining it, noone else would be able to, if I
> > understand the licensing issues correctly.
> > Is there a chance of these licensing issues being cleared up so that the
> > backend can be released under a more permissive license? If not, while I
> > understand Walter's decision to use a backend he was familiar with in the
> > beginning, it seems like we should abandon such a heavily encumbered
> backend
> > now that it needs serious work.
>> Hi
>> I agree with what Sean says. Even more, DMD backend is good for development
> process, because it is very fast as opposed to more popular ones like llvm
> or gcc.
> What really worries me is what is going to happen on Windows. We have the
> burden
> which is old file format and optlink. There are still big problems with the
> linker, it has random problems on big projects, building them with debug
> info is
> even more problematic. As far as I understood that linker is being
> rewritten to C,
> but the process is very slow. It may take years to complete the port, and
> then to
> make it 64bit capable, isn't it? All existing problems would be propagated
> further. I would suggest(again and again) to add a new Windows backend
> targeting
> MinGW or MSVC toolchain. It should not necessarily replace the existing
> one, but
> people would at least have freedom and there wouldn't be situation that you
> are
> stuck in development when linker fails. Also those toolchain support 64bit,
> so it
> is another advantage. For those who still wants digital mars toolchain -
> there
> will be an old one. Remembering that it took Walter about 6 weeks to
> implement
> MacOS backend, that doesn't seem too bad. In the end, Windows is the most
> popular
> OS despite our personal preferences, and it's worth spending some time for
> it.
>> Cheers
>

Hello Leandro,
> Nick Sabalausky, el 21 de junio a las 13:40 me escribiste:
> >> "Eldar Insafutdinov" <e.insafutdinov@gmail.com> wrote in message
>> news:hvo49k$1uk3$1@digitalmars.com...>> >>> In the end, Windows is the most popular
>>> OS despite our personal preferences, and it's worth spending some
>>> time for
>>> it.
>> I wish someone could convince LLVM of that...
>> > Maybe it should be the other way around. Someone who cares about
> Windows should give some love to LLVM =)
>
How hard are the problems? I have zero experience in LLVM and very little in compiler work but if the problems could be attacked without to much ramp-up I'd be interested in looking into them.
--
... <IXOYE><

Hello Robert,
> On 21/06/10 16:07, dsimcha wrote:
> >> What is the long-term plan for the current DMD backend? I've noticed
>> the
>> first steps towards 64-bit support were just checked in today
>> (excitement to
>> the extreme). However, the backend is under such a restrictive
>> license (which
>> I understand Walter is not free to change) that it has a "bus factor"
>> of 1.
>> If Walter were to stop maintaining it, noone else would be able to,
>> if I
>> understand the licensing issues correctly.
>> Is there a chance of these licensing issues being cleared up so that
>> the backend can be released under a more permissive license? If not,
>> while I understand Walter's decision to use a backend he was familiar
>> with in the beginning, it seems like we should abandon such a heavily
>> encumbered backend now that it needs serious work.
>> > Perhaps the 64bit backend could be written in such a way that it
> doesn't have the licensing issues? I have no idea what the specifics
> are to say if this is possible, it'd be good to not have the 64 bit
> backend under the current backend license though.
I'm going to guess that about half of the object file generator and nearly 100% of everything before the code generator will be the same for 32 and 64 bit. And at a wild guess I'm going to say that's much more than half the code in the back end. Add an error factor for me guessing and you can do the math. :(
> --
... <IXOYE><

On Mon, 21 Jun 2010 23:55:48 -0400, BCS <none@anon.com> wrote:
> Hello Leandro,
>>> Nick Sabalausky, el 21 de junio a las 13:40 me escribiste:
>>>>> "Eldar Insafutdinov" <e.insafutdinov@gmail.com> wrote in message
>>> news:hvo49k$1uk3$1@digitalmars.com...>>>>>>> In the end, Windows is the most popular
>>>> OS despite our personal preferences, and it's worth spending some
>>>> time for
>>>> it.
>>> I wish someone could convince LLVM of that...
>>>>> Maybe it should be the other way around. Someone who cares about
>> Windows should give some love to LLVM =)
>>>> How hard are the problems? I have zero experience in LLVM and very little in compiler work but if the problems could be attacked without to much ramp-up I'd be interested in looking into them.
>
The main issue (as I understand it) is adding windows style structured exception handling to LLVM.