64-bit support
Bill Baxter
dnewsgroup at billbaxter.com
Wed Feb 13 22:31:20 PST 2008
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
More information about the Digitalmars-d
mailing list