www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 64-bit support

reply Graham St Jack <Graham.StJack internode.on.net> writes:
Can anyone tell me what the situation is with 64-bit support in DMD? Like 
when is it likely to happen?
Feb 12 2008
parent reply doob <doobnet gmail.com> writes:
Graham St Jack wrote:

 Can anyone tell me what the situation is with 64-bit support in DMD? Like 
 when is it likely to happen?


I  don't think it's likely to happen, because DMD uses a backend that 
already existed before D and that has only 32bit support. But there's 
always GDC with 64bit support, at least on windows.
Feb 12 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
doob wrote:

 Graham St Jack wrote:

 Can anyone tell me what the situation is with 64-bit support in DMD? 
 Like when is it likely to happen?


 
 I  don't think it's likely to happen, because DMD uses a backend that 
 already existed before D and that has only 32bit support. But there's 
 always GDC with 64bit support, at least on windows.


I've got hopes that one day an LLVM-based D compiler will be the one D 
compiler to rule them all.
(There's a start of one limping along at 
http://www.dsource.org/projects/llvmdc).

--bb
Feb 12 2008
next sibling parent "Craig Black" <craigblack2 cox.net> writes:
 I've got hopes that one day an LLVM-based D compiler will be the one D 
 compiler to rule them all.
 (There's a start of one limping along at 
 http://www.dsource.org/projects/llvmdc).
 
 --bb


Very good news!  I hope this gets more attention.
Feb 12 2008
prev sibling parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
 I've got hopes that one day an LLVM-based D compiler will be the one D
 compiler to rule them all.
 (There's a start of one limping along at
 http://www.dsource.org/projects/llvmdc).


Sounds great - looking forward to it.
Feb 12 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Graham St Jack wrote:

 I've got hopes that one day an LLVM-based D compiler will be the one D
 compiler to rule them all.
 (There's a start of one limping along at
 http://www.dsource.org/projects/llvmdc).


 
 Sounds great - looking forward to it.


Yeh, me too.  But I'm afraid that unless it becomes someone's full-time 
obsession, realistically it's never going to be ready for prime time.

Thomas L. Olsen has gotten it off to a good start as his hobby project, 
despite apparently starting from zero knowledge of how LLVM works.  But 
I don't think his spare time effort is really going to be enough to 
create a competitive compiler, ultimately.

Hopefully the good start he's provided will attract the attention of 
someone with time and knowledge enough to carry it through to the finish 
line.  Or perhaps TLO himself will find some way to make it happen.

[Dreaming] Before too long here, not supporting 64-bit architectures is 
going to become an untenable position for any compiler.  As that day 
approaches, eventually Walter himself may decide that switching to the 
LLVM back-end makes the most sense.  If so then LLVMDC would give him a 
nice start, I think.

--bb
Feb 12 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 eventually Walter himself may decide that switching to the 
 LLVM back-end makes the most sense.


LLVM may allow D to do certain things that today are difficult, like run-time
creation of routines (they can be created by macros too), and other dynamic

CommonLisp programmers may find attractive ;-)

Bye,
bearophile
Feb 13 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
bearophile wrote:

 Bill Baxter:

 eventually Walter himself may decide that switching to the 
 LLVM back-end makes the most sense.


 
 LLVM may allow D to do certain things that today are difficult, like run-time
creation of routines (they can be created by macros too), and other dynamic

CommonLisp programmers may find attractive ;-)


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
Feb 13 2008
next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 14 Feb 2008 09:11:58 +0900, Bill Baxter wrote:


 bearophile wrote:

 Bill Baxter:

 eventually Walter himself may decide that switching to the LLVM
 back-end makes the most sense.


 
 LLVM may allow D to do certain things that today are difficult, like
 run-time creation of routines (they can be created by macros too), and

 create something that even CommonLisp programmers may find attractive
 ;-)


 
 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


Maybe it could be something to push for, for D3.
Feb 13 2008
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
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
Feb 13 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 13 2008
parent reply John Reimer <terminal.node gmail.com> writes:
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
Feb 13 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 13 2008
parent reply Gilles G. <schaouette free.fr> writes:
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
Feb 13 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 14 2008
next sibling parent Gilles G. <schaouette free.fr> writes:
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.
Feb 14 2008
prev sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
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.
Feb 14 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Tomas Lindquist Olsen wrote:

 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.


Last I checked, llvm exception handling claimed to be rather specific to 
C++'s exception mechanism, since no other languages with exception 
handling had llvm compilers. Do you have any idea how difficult it will 
be to use that system for D?
Feb 14 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
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.
Feb 14 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
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/


(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


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
Feb 14 2008
prev sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Wed, 13 Feb 2008 14:13:48 +0900, Bill Baxter wrote:


 Graham St Jack wrote:

 I've got hopes that one day an LLVM-based D compiler will be the one D
 compiler to rule them all.
 (There's a start of one limping along at
 http://www.dsource.org/projects/llvmdc).


 
 Sounds great - looking forward to it.


 
 Yeh, me too.  But I'm afraid that unless it becomes someone's full-time
 obsession, realistically it's never going to be ready for prime time.
 
 Thomas L. Olsen has gotten it off to a good start as his hobby project,
 despite apparently starting from zero knowledge of how LLVM works.  But
 I don't think his spare time effort is really going to be enough to
 create a competitive compiler, ultimately.
 
 Hopefully the good start he's provided will attract the attention of
 someone with time and knowledge enough to carry it through to the finish
 line.  Or perhaps TLO himself will find some way to make it happen.
 
 [Dreaming] Before too long here, not supporting 64-bit architectures is
 going to become an untenable position for any compiler.  As that day
 approaches, eventually Walter himself may decide that switching to the
 LLVM back-end makes the most sense.  If so then LLVMDC would give him a
 nice start, I think.


I agree.
Feb 13 2008