64-bit support

[John Reimer]

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