64-bit support

[Bill Baxter]

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