Bill Baxter wrote:

> Not to mention that it should fix a raft of other long-standing bugs that have to do with OPTLINK.  I'm pretty convinced that LLVM is the way to go long term.  It would free Walter up from having to deal with back end issues, but still allow him to tinker with the back end or contribute patches to the LLVM team if he needs something to be fixed for D.  It would allow D to benefit from a world wide community working on porting to new back-end targets, and making improvements to the optimizer etc. Not to mention allowing D to piggyback on the corporate support from the likes of Apple that is going into LLVM right now.
> 
> I see basically no down sides to such a move, other than making the move would initially be a big time suck.  But I think the writing is on the wall that OPTLINK will have to be replaced eventually one way or another.  Going with LLVM looks to be the best way to do that in terms of cost/benefit ratios.
> 
> --bb


Wouldn't there be the exact same issue that keeps Walter from personally merging dmd frontend with the gcc backend (I believe llvm is based on gcc technology)?  It would have been optimal long ago for him to be working on something like gdc as the reference compiler, but he apparently can not look upon another compiler's source (including gcc, especially the backend) because this could "taint" his closed source property.  :(

It would have to be another person that worked on the back-end target. Walter would have to develop tag-team: ie. he would improve the frontend and have someone else work on the back end.  And I don't think he's likely to "handicap" himself that way.  I think this was one topic that came up on this list many times...

It's really quite unfortunate that this is such an issue with the D language and it's compiler because it really keeps the toolset from going where it should have gone long ago -- a completely open source compiler system spearheaded by the designer.  Any developer that starts a new D compiler project is forced to track with Walter's closed-source-backend D compiler.  This is why gdc fails to keep up. This will be the case with every other compiler out there that tries to do the same.

Sorry for the pessimism... Maybe there's a way to solve this problem?

-JJR

John Reimer wrote:
> Bill Baxter wrote:
> 
>> Not to mention that it should fix a raft of other long-standing bugs that have to do with OPTLINK.  I'm pretty convinced that LLVM is the way to go long term.  It would free Walter up from having to deal with back end issues, but still allow him to tinker with the back end or contribute patches to the LLVM team if he needs something to be fixed for D.  It would allow D to benefit from a world wide community working on porting to new back-end targets, and making improvements to the optimizer etc. Not to mention allowing D to piggyback on the corporate support from the likes of Apple that is going into LLVM right now.
>>
>> I see basically no down sides to such a move, other than making the move would initially be a big time suck.  But I think the writing is on the wall that OPTLINK will have to be replaced eventually one way or another.  Going with LLVM looks to be the best way to do that in terms of cost/benefit ratios.
>>
>> --bb
> 
> 
> Wouldn't there be the exact same issue that keeps Walter from personally merging dmd frontend with the gcc backend (I believe llvm is based on gcc technology)?  It would have been optimal long ago for him to be working on something like gdc as the reference compiler, but he apparently can not look upon another compiler's source (including gcc, especially the backend) because this could "taint" his closed source property.  :(

Nope.  LLVM license is not GPL.  It looks to be basically a ZLIB/PNG type licence.  Very brief.  Very few strings attached.

> It would have to be another person that worked on the back-end target. Walter would have to develop tag-team: ie. he would improve the frontend and have someone else work on the back end.  And I don't think he's likely to "handicap" himself that way.  I think this was one topic that came up on this list many times...

Don't think it's an issue with LLVM and its license.

> It's really quite unfortunate that this is such an issue with the D language and it's compiler because it really keeps the toolset from going where it should have gone long ago -- a completely open source compiler system spearheaded by the designer.  Any developer that starts a new D compiler project is forced to track with Walter's closed-source-backend D compiler.  This is why gdc fails to keep up. This will be the case with every other compiler out there that tries to do the same.
> 
> Sorry for the pessimism... Maybe there's a way to solve this problem?

Good news!  There's no problem that needs solving w.r.t. LLVM, as far as I can tell.

--bb

Bill Baxter wrote:
> John Reimer wrote:
>> Bill Baxter wrote:
>>
>>> Not to mention that it should fix a raft of other long-standing bugs that have to do with OPTLINK.  I'm pretty convinced that LLVM is the way to go long term.  It would free Walter up from having to deal with back end issues, but still allow him to tinker with the back end or contribute patches to the LLVM team if he needs something to be fixed for D.  It would allow D to benefit from a world wide community working on porting to new back-end targets, and making improvements to the optimizer etc. Not to mention allowing D to piggyback on the corporate support from the likes of Apple that is going into LLVM right now.
>>>
>>> I see basically no down sides to such a move, other than making the move would initially be a big time suck.  But I think the writing is on the wall that OPTLINK will have to be replaced eventually one way or another.  Going with LLVM looks to be the best way to do that in terms of cost/benefit ratios.
>>>
>>> --bb
>>
>>
>> Wouldn't there be the exact same issue that keeps Walter from personally merging dmd frontend with the gcc backend (I believe llvm is based on gcc technology)?  It would have been optimal long ago for him to be working on something like gdc as the reference compiler, but he apparently can not look upon another compiler's source (including gcc, especially the backend) because this could "taint" his closed source property.  :(
> 
> Nope.  LLVM license is not GPL.  It looks to be basically a ZLIB/PNG type licence.  Very brief.  Very few strings attached.
> 
>> It would have to be another person that worked on the back-end target. Walter would have to develop tag-team: ie. he would improve the frontend and have someone else work on the back end.  And I don't think he's likely to "handicap" himself that way.  I think this was one topic that came up on this list many times...
> 
> Don't think it's an issue with LLVM and its license.
> 
>> It's really quite unfortunate that this is such an issue with the D language and it's compiler because it really keeps the toolset from going where it should have gone long ago -- a completely open source compiler system spearheaded by the designer.  Any developer that starts a new D compiler project is forced to track with Walter's closed-source-backend D compiler.  This is why gdc fails to keep up. This will be the case with every other compiler out there that tries to do the same.
>>
>> Sorry for the pessimism... Maybe there's a way to solve this problem?
> 
> Good news!  There's no problem that needs solving w.r.t. LLVM, as far as I can tell.
> 
> --bb


That does appear to be good news... Now if only Walter would take notice.  This would be the first time (I think) that this argument has been effectively removed. :)

-JJR

-JJR

John Reimer wrote:
> Bill Baxter wrote:
>> John Reimer wrote:
>>> Bill Baxter wrote:
>>>
>>>> Not to mention that it should fix a raft of other long-standing bugs that have to do with OPTLINK.  I'm pretty convinced that LLVM is the way to go long term.  It would free Walter up from having to deal with back end issues, but still allow him to tinker with the back end or contribute patches to the LLVM team if he needs something to be fixed for D.  It would allow D to benefit from a world wide community working on porting to new back-end targets, and making improvements to the optimizer etc. Not to mention allowing D to piggyback on the corporate support from the likes of Apple that is going into LLVM right now.
>>>>
>>>> I see basically no down sides to such a move, other than making the move would initially be a big time suck.  But I think the writing is on the wall that OPTLINK will have to be replaced eventually one way or another.  Going with LLVM looks to be the best way to do that in terms of cost/benefit ratios.
>>>>
>>>> --bb
>>>
>>>
>>> Wouldn't there be the exact same issue that keeps Walter from personally merging dmd frontend with the gcc backend (I believe llvm is based on gcc technology)?  It would have been optimal long ago for him to be working on something like gdc as the reference compiler, but he apparently can not look upon another compiler's source (including gcc, especially the backend) because this could "taint" his closed source property.  :(
>>
>> Nope.  LLVM license is not GPL.  It looks to be basically a ZLIB/PNG type licence.  Very brief.  Very few strings attached.
>>
>>> It would have to be another person that worked on the back-end target. Walter would have to develop tag-team: ie. he would improve the frontend and have someone else work on the back end.  And I don't think he's likely to "handicap" himself that way.  I think this was one topic that came up on this list many times...
>>
>> Don't think it's an issue with LLVM and its license.
>>
>>> It's really quite unfortunate that this is such an issue with the D language and it's compiler because it really keeps the toolset from going where it should have gone long ago -- a completely open source compiler system spearheaded by the designer.  Any developer that starts a new D compiler project is forced to track with Walter's closed-source-backend D compiler.  This is why gdc fails to keep up. This will be the case with every other compiler out there that tries to do the same.
>>>
>>> Sorry for the pessimism... Maybe there's a way to solve this problem?
>>
>> Good news!  There's no problem that needs solving w.r.t. LLVM, as far as I can tell.
>>
>> --bb
> 
> 
> That does appear to be good news... Now if only Walter would take notice.  This would be the first time (I think) that this argument has been effectively removed. :)
> 
> -JJR

I think the main problem is that there isn't actually even a proven C++ built on top of LLVM at this point.  But rumor is that Apple wants to move away from GCC and make an LLVM-based compiler their primary compiler.  So whatever needs to be done to make it a reality is no doubt going to be done.  Given that, it seems to me like now is the perfect time to be working on the D front end for it, while LLVM folks are still probably receptive to big architectural changes to support a proper C++ compiler.  D is different enough -- but at the same time similar enough -- that it makes sense to have it in the mix.  That way LLVM people won't be lulled into thinking something is generally true when it's really a C/C++-specific assumption.   If that makes sense.

I guess ObjC is probably similar in that respect, and no doubt Apple wants an ObjC front end too.  Maybe that's sufficient to keep 'em honest and not make C/C++ specific assumptions.  But maybe not, since I think ObjC is also a superset of C.

--bb

Bill Baxter Wrote:
> I think the main problem is that there isn't actually even a proven C++ built on top of LLVM at this point.  But rumor is that Apple wants to move away from GCC and make an LLVM-based compiler their primary compiler.  So whatever needs to be done to make it a reality is no doubt going to be done.  Given that, it seems to me like now is the perfect time to be working on the D front end for it, while LLVM folks are still probably receptive to big architectural changes to support a proper C++ compiler.  D is different enough -- but at the same time similar enough -- that it makes sense to have it in the mix.  That way LLVM people won't be lulled into thinking something is generally true when it's really a C/C++-specific assumption.   If that makes sense.
> 
> I guess ObjC is probably similar in that respect, and no doubt Apple wants an ObjC front end too.  Maybe that's sufficient to keep 'em honest and not make C/C++ specific assumptions.  But maybe not, since I think ObjC is also a superset of C.
> 
> --bb
You can take a look at http://llvm.org/Features.html .
you will see that LLVM already as "complete" front-ends for C, C++, and ObjC. These front-end are based upon GCC's ones.

--
Gilles

Gilles G. wrote:
> Bill Baxter Wrote:
>> I think the main problem is that there isn't actually even a proven C++ built on top of LLVM at this point.  But rumor is that Apple wants to move away from GCC and make an LLVM-based compiler their primary compiler.  So whatever needs to be done to make it a reality is no doubt going to be done.  Given that, it seems to me like now is the perfect time to be working on the D front end for it, while LLVM folks are still probably receptive to big architectural changes to support a proper C++ compiler.  D is different enough -- but at the same time similar enough -- that it makes sense to have it in the mix.  That way LLVM people won't be lulled into thinking something is generally true when it's really a C/C++-specific assumption.   If that makes sense.
>>
>> I guess ObjC is probably similar in that respect, and no doubt Apple wants an ObjC front end too.  Maybe that's sufficient to keep 'em honest and not make C/C++ specific assumptions.  But maybe not, since I think ObjC is also a superset of C.
>>
>> --bb
> You can take a look at http://llvm.org/Features.html .
> you will see that LLVM already as "complete" front-ends for C, C++, and ObjC. These front-end are based upon GCC's ones.
> 

But have they been used to compile any significantly big piece of software?  Like, say, a sizeable wxWidgets project such as Audacity?

--bb

Bill Baxter Wrote:

> Gilles G. wrote:
> > Bill Baxter Wrote:
> >> I think the main problem is that there isn't actually even a proven C++ built on top of LLVM at this point.  But rumor is that Apple wants to move away from GCC and make an LLVM-based compiler their primary compiler.  So whatever needs to be done to make it a reality is no doubt going to be done.  Given that, it seems to me like now is the perfect time to be working on the D front end for it, while LLVM folks are still probably receptive to big architectural changes to support a proper C++ compiler.  D is different enough -- but at the same time similar enough -- that it makes sense to have it in the mix.  That way LLVM people won't be lulled into thinking something is generally true when it's really a C/C++-specific assumption.   If that makes sense.
> >>
> >> I guess ObjC is probably similar in that respect, and no doubt Apple wants an ObjC front end too.  Maybe that's sufficient to keep 'em honest and not make C/C++ specific assumptions.  But maybe not, since I think ObjC is also a superset of C.
> >>
> >> --bb
> > You can take a look at http://llvm.org/Features.html .
> > you will see that LLVM already as "complete" front-ends for C, C++, and ObjC. These front-end are based upon GCC's ones.
> > 
> 
> But have they been used to compile any significantly big piece of software?  Like, say, a sizeable wxWidgets project such as Audacity?
> 
> --bb
Yes, LLVM compiles Qt for example.

Here is an example of code you can do when D has the LLVM behind.
There is an interesting book titled "Beautiful code", this is the code that goes with the book:
http://examples.oreilly.com/9780596510046/

In the "Petzold" directory there is an example of using C# for image processing (image filtering), if you take a look at the "ImageFilter.cs" file you can see it creates ops for the VirtualMachine on the fly, to speed up the program. That C# routine is full of lines like:

Label labelDone = generator.DefineLabel();
// Divide pixelsAccum by filterAccum
generator.Emit(OpCodes.Ldloc_1); // pixelsAccum
generator.Emit(OpCodes.Ldloc_2); // filterAccum

(I think a Lisp programmer may think bad things about that code, because Lisp macros may be better for that purpose).
I presume with D it's not too much difficult to do something similar defining that code at compile time using templates & mixins. But at the moment you can only do that at compile time (you can build assembly routines on the fly and call them, I have seen such things done in C, but it's not easy and you have to know assembly well enough, etc). With LLVM backend this can be done at runtime too, and with a good enough syntax (ideally like in Python, you can write D code in a string, and compile it at run time to create a new function, if you don't want to use the low level instructions of the LLVM).

Note: at the moment LLVM is able to compile C++ code, but from my few benchmarks the resulting executable isn't speed-optimized well enough as the same code compiled by MinGW with GCC 3.2 (around you can find 4.2.1 too: ttp://nuwen.net/mingw.html ). The difference may be little (less than 15% in my benchmarks), but it can be found in 30-lines long programs too.

Bye,
bearophile

John Reimer wrote:
> Sorry for the pessimism... Maybe there's a way to solve this problem?
> 
> -JJR

Popularity. Have people working on llvmdc until it's up to date with dmd, and updates within a day or two of dmd updates. Then ask Walter to offer it for download on digitalmars. Have everyone stop using dmd.

Walter then would be nearly compelled to work with the llvmdc team. But that's contingent on there being such a team.

Bill Baxter wrote:
> Gilles G. wrote:
>> Bill Baxter Wrote:
>>> I think the main problem is that there isn't actually even a proven C++ built on top of LLVM at this point.  But rumor is that Apple wants to move away from GCC and make an LLVM-based compiler their primary compiler.  So whatever needs to be done to make it a reality is no doubt going to be done.  Given that, it seems to me like now is the perfect time to be working on the D front end for it, while LLVM folks are still probably receptive to big architectural changes to support a proper C++ compiler.  D is different enough -- but at the same time similar enough -- that it makes sense to have it in the mix.  That way LLVM people won't be lulled into thinking something is generally true when it's really a C/C++-specific assumption.   If that makes sense.
>>>
>>> I guess ObjC is probably similar in that respect, and no doubt Apple wants an ObjC front end too.  Maybe that's sufficient to keep 'em honest and not make C/C++ specific assumptions.  But maybe not, since I think ObjC is also a superset of C.
>>>
>>> --bb
>> You can take a look at http://llvm.org/Features.html .
>> you will see that LLVM already as "complete" front-ends for C, C++, and ObjC. These front-end are based upon GCC's ones.
>>
> 
> But have they been used to compile any significantly big piece of software?  Like, say, a sizeable wxWidgets project such as Audacity?
> 
> --bb

Thanx for bringing some attention to my llvmdc project :)

I'll just jump in here and add that the llvm-gcc project is very mature and in most aspects at least as functional as the original gcc. All the backends however are not yet fully up to speed, but x86 is very well supported. There are some problems with exceptions on other targets afaik, but these are all being sorted out. The just-out LLVM 2.2 release is much closer than they've been before and I suspect 2.3 will put an end to most of the big issues.