Jump to page: 1 26  
Page
Thread overview
DMD Backend Long-term
Jun 21, 2010
dsimcha
Jun 21, 2010
Sean Kelly
Jun 21, 2010
Eldar Insafutdinov
Jun 21, 2010
Nick Sabalausky
Jun 21, 2010
Leandro Lucarella
Jun 22, 2010
BCS
Jun 22, 2010
Robert Jacques
Jun 22, 2010
Kagamin
Jun 22, 2010
Leandro Lucarella
Jun 23, 2010
BCS
Jun 22, 2010
BCS
Jun 22, 2010
Robert Jacques
Jun 22, 2010
Nick Sabalausky
Jun 22, 2010
Brad Roberts
Jun 23, 2010
dsimcha
Jun 23, 2010
BCS
Jun 23, 2010
dsimcha
Jun 23, 2010
BCS
Jun 29, 2010
BCS
Jul 06, 2010
Nick Sabalausky
Jul 06, 2010
David Gileadi
Jun 23, 2010
BCS
Jun 23, 2010
Brad Roberts
Jun 23, 2010
BCS
Jun 23, 2010
Nick Sabalausky
Jun 23, 2010
BCS
Jun 23, 2010
Nick Sabalausky
Jun 22, 2010
bearophile
Jun 23, 2010
Leandro Lucarella
Jun 23, 2010
bearophile
Jun 23, 2010
BCS
Jun 23, 2010
Leandro Lucarella
Jun 23, 2010
bearophile
Jun 23, 2010
Justin Johansson
Jun 23, 2010
BCS
Jun 23, 2010
KennyTM~
Jun 23, 2010
Nick Sabalausky
Jun 24, 2010
Kagamin
Jun 23, 2010
BCS
Jun 23, 2010
Nick Sabalausky
Jun 23, 2010
Leandro Lucarella
Jun 23, 2010
Leandro Lucarella
Jun 23, 2010
Todd VanderVeen
Jun 23, 2010
BCS
Jun 23, 2010
Jérôme M. Berger
Jun 23, 2010
bearophile
Jun 23, 2010
KennyTM~
Jun 23, 2010
Don
Jun 24, 2010
BCS
Jun 23, 2010
Jérôme M. Berger
Jun 24, 2010
BCS
Jun 24, 2010
Nick Sabalausky
Jun 24, 2010
BCS
Jun 21, 2010
Long Chang
Jun 21, 2010
Robert Clipsham
Jun 22, 2010
BCS
June 21, 2010
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.
June 21, 2010
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.
June 21, 2010
== 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
June 21, 2010
"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...


June 21, 2010
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.
June 21, 2010
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 =)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Es mucho mas probable que el salchichón sea primavera a que la primavera
sea salchichón.
	-- Peperino Pómoro
June 21, 2010
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
>


June 22, 2010
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><



June 22, 2010
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><



June 22, 2010
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.
« First   ‹ Prev
1 2 3 4 5 6