64-bit support

[Bill Baxter]

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