www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should LLVM become the default D-lang platform?

reply "Dwhatever" <not real.com> writes:
This might have been brought up before but I couldn't find any 
thread about this. As things has progressed I wonder if Digital 
Mars DMD should move over to use LLVM instead of its own code 
generation and compiler framework.

As I see it with the small amount of contributors D-language has, 
DMD will never support anything beyond x86 as there are no 
resources for this. Also, why spend time on recreating the the 
code generation which has already been done with LLVM? This 
enables this community to focus on the language which is the most 
important part as well as supporting more and future processor 
targets.
Jan 10 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any 
 thread about this. As things has progressed I wonder if Digital 
 Mars DMD should move over to use LLVM instead of its own code 
 generation and compiler framework.

 As I see it with the small amount of contributors D-language 
 has, DMD will never support anything beyond x86 as there are no 
 resources for this. Also, why spend time on recreating the the 
 code generation which has already been done with LLVM? This 
 enables this community to focus on the language which is the 
 most important part as well as supporting more and future 
 processor targets.


This comes up regularly. It's already been done. Ldc *is* dmd 
with llvm backend. Gdc is the same idea but with the gcc 
framework.
Jan 10 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 10 January 2014 at 20:54:06 UTC, John Colvin wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any 
 thread about this. As things has progressed I wonder if 
 Digital Mars DMD should move over to use LLVM instead of its 
 own code generation and compiler framework.

 As I see it with the small amount of contributors D-language 
 has, DMD will never support anything beyond x86 as there are 
 no resources for this. Also, why spend time on recreating the 
 the code generation which has already been done with LLVM? 
 This enables this community to focus on the language which is 
 the most important part as well as supporting more and future 
 processor targets.


 This comes up regularly. It's already been done. Ldc *is* dmd 
 with llvm backend. Gdc is the same idea but with the gcc 
 framework.


also, the digital mars backend is very fast, which is actually 
good selling point for some use-cases where compilation speed is 
important.
Jan 10 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/10/14 12:56 PM, John Colvin wrote:

 On Friday, 10 January 2014 at 20:54:06 UTC, John Colvin wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any thread
 about this. As things has progressed I wonder if Digital Mars DMD
 should move over to use LLVM instead of its own code generation and
 compiler framework.

 As I see it with the small amount of contributors D-language has, DMD
 will never support anything beyond x86 as there are no resources for
 this. Also, why spend time on recreating the the code generation
 which has already been done with LLVM? This enables this community to
 focus on the language which is the most important part as well as
 supporting more and future processor targets.


 This comes up regularly. It's already been done. Ldc *is* dmd with
 llvm backend. Gdc is the same idea but with the gcc framework.


 also, the digital mars backend is very fast, which is actually good
 selling point for some use-cases where compilation speed is important.


We plan to rig Facebook's build system to use dmd in debug mode and gdc 
in release mode by default. Best of both worlds.

Andrei
Jan 10 2014
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Friday, 10 January 2014 at 21:44:52 UTC, Andrei Alexandrescu 
wrote:

 We plan to rig Facebook's build system to use dmd in debug mode 
 and gdc in release mode by default. Best of both worlds.

 Andrei


Speaking of Facebook, I'd be interested in seeing how your lexer 
generator ended up compared to mine. Did you ever get permission 
to release that code?
Jan 10 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/10/14 1:58 PM, Brian Schott wrote:

 On Friday, 10 January 2014 at 21:44:52 UTC, Andrei Alexandrescu wrote:

 We plan to rig Facebook's build system to use dmd in debug mode and
 gdc in release mode by default. Best of both worlds.

 Andrei


 Speaking of Facebook, I'd be interested in seeing how your lexer
 generator ended up compared to mine. Did you ever get permission to
 release that code?


Yes, it's in the pipeline.

Andrei
Jan 10 2014
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 10 Jan 2014 13:44:52 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:


 We plan to rig Facebook's build system to use dmd in debug mode and gdc 
 in release mode by default. Best of both worlds.
 
 Andrei


I do that too, and part of the reason why I hacked something
together for the Gentoo Linux package manager, so I could
install libraries for multiple compilers at once.
It seems so trivial to use dmd and a companion compiler gdc
or ldc, but once shared libraries and multiple D releases come
into the mix, it means patching up dmd, make files and dealing
with "rpath" to load the correct .so (compiler using a
specific compiler vendor/version combination).

-- 
Marco
Jan 11 2014
prev sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 10.01.2014 21:56, schrieb John Colvin:

 also, the digital mars backend is very fast, which is actually good
 selling point for some use-cases where compilation speed is important.


I would also prefer to keep the digital mars backend for exactly that 
reason. The GCC and LLVM backends are just way to slow.

Kind Regards
Benjamin Thaut
Jan 11 2014
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 10 January 2014 20:54, John Colvin <john.loughran.colvin gmail.com> wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any thread
 about this. As things has progressed I wonder if Digital Mars DMD should
 move over to use LLVM instead of its own code generation and compiler
 framework.

 As I see it with the small amount of contributors D-language has, DMD will
 never support anything beyond x86 as there are no resources for this. Also,
 why spend time on recreating the the code generation which has already been
 done with LLVM? This enables this community to focus on the language which
 is the most important part as well as supporting more and future processor
 targets.



 This comes up regularly. It's already been done. Ldc *is* dmd with llvm
 backend. Gdc is the same idea but with the gcc framework.


Indeed. But naturally I'd suggest they move to GCC.  ;-)
Jan 10 2014
parent reply "Dwhatever" <not real.com> writes:
On Friday, 10 January 2014 at 20:59:35 UTC, Iain Buclaw wrote:

 On 10 January 2014 20:54, John Colvin 
 <john.loughran.colvin gmail.com> wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find 
 any thread
 about this. As things has progressed I wonder if Digital Mars 
 DMD should
 move over to use LLVM instead of its own code generation and 
 compiler
 framework.

 As I see it with the small amount of contributors D-language 
 has, DMD will
 never support anything beyond x86 as there are no resources 
 for this. Also,
 why spend time on recreating the the code generation which 
 has already been
 done with LLVM? This enables this community to focus on the 
 language which
 is the most important part as well as supporting more and 
 future processor
 targets.



 This comes up regularly. It's already been done. Ldc *is* dmd 
 with llvm
 backend. Gdc is the same idea but with the gcc framework.


 Indeed. But naturally I'd suggest they move to GCC.  ;-)


I see LLVM as a better choice because the license is less 
intrusive.
Jan 10 2014
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 10 January 2014 21:02, Dwhatever <not real.com> wrote:

 I see LLVM as a better choice because the license is less intrusive.


That is a rather ignorant assumption.
Jan 10 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 10 January 2014 at 21:12:21 UTC, Iain Buclaw wrote:

 On 10 January 2014 21:02, Dwhatever <not real.com> wrote:

 I see LLVM as a better choice because the license is less 
 intrusive.


 That is a rather ignorant assumption.


I've got some pretty strong sympathies with the gpl, but really? 
In most practical circumstances gpl is on the more restrictive 
end of common open-source licences.
Jan 10 2014
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/01/14 22:24, John Colvin wrote:

 I've got some pretty strong sympathies with the gpl, but really? In most
 practical circumstances gpl is on the more restrictive end of common
open-source
 licences.


Yes, but there's a difference between "restrictive" and "intrusive".  Using GDC 
doesn't intrude into anything -- the standard libraries are still
Boost-licensed 
and simply _using_ a GPL'd piece of software doesn't place any obligations on
you.
Jan 10 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-01-10 23:16, Joseph Rushton Wakeling wrote:


 Yes, but there's a difference between "restrictive" and "intrusive".
 Using GDC doesn't intrude into anything -- the standard libraries are
 still Boost-licensed and simply _using_ a GPL'd piece of software
 doesn't place any obligations on you.


The way Apple has integrated Clang into Xcode would never be possible 
with GCC since that would require Apple to release Xcode under the GPL 
license.

-- 
/Jacob Carlborg
Jan 11 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Saturday, 11 January 2014 at 20:38:32 UTC, Jacob Carlborg 
wrote:

 On 2014-01-10 23:16, Joseph Rushton Wakeling wrote:


 Yes, but there's a difference between "restrictive" and 
 "intrusive".
 Using GDC doesn't intrude into anything -- the standard 
 libraries are
 still Boost-licensed and simply _using_ a GPL'd piece of 
 software
 doesn't place any obligations on you.


 The way Apple has integrated Clang into Xcode would never be 
 possible with GCC since that would require Apple to release 
 Xcode under the GPL license.


Right, but they are not merely using -- they are redistributing 
(and distributing derivative works).  The GPL places certain 
constraints here, I think we can all agree, but it can hardly be 
described as "intrusive"; there's no obligation to base one's 
work on GPL-licensed code.
Jan 13 2014
next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 13 January 2014 08:07, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:

 On Saturday, 11 January 2014 at 20:38:32 UTC, Jacob Carlborg wrote:

 On 2014-01-10 23:16, Joseph Rushton Wakeling wrote:


 Yes, but there's a difference between "restrictive" and "intrusive".
 Using GDC doesn't intrude into anything -- the standard libraries are
 still Boost-licensed and simply _using_ a GPL'd piece of software
 doesn't place any obligations on you.



 The way Apple has integrated Clang into Xcode would never be possible with
 GCC since that would require Apple to release Xcode under the GPL license.



 Right, but they are not merely using -- they are redistributing (and
 distributing derivative works).  The GPL places certain constraints here, I
 think we can all agree, but it can hardly be described as "intrusive";
 there's no obligation to base one's work on GPL-licensed code.


Yah, but s/constraints/freedoms/.  :-)
Jan 13 2014
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/01/14 09:13, Iain Buclaw wrote:

 Yah, but s/constraints/freedoms/.  :-)


Quite. :-)
Jan 13 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-01-13 09:07, Joseph Rushton Wakeling wrote:


 Right, but they are not merely using -- they are redistributing (and
 distributing derivative works).  The GPL places certain constraints
 here, I think we can all agree, but it can hardly be described as
 "intrusive"; there's no obligation to base one's work on GPL-licensed code.


I think the "intrusive" part referrers to, if you use GPL licensed code 
your own coded need to be GPL licensed as well.

-- 
/Jacob Carlborg
Jan 13 2014
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Monday, 13 January 2014 at 08:07:42 UTC, Joseph Rushton 
Wakeling wrote:

 Right, but they are not merely using -- they are redistributing 
 (and distributing derivative works).  The GPL places certain 
 constraints here, I think we can all agree, but it can hardly 
 be described as "intrusive"; there's no obligation to base 
 one's work on GPL-licensed code.


If the whole topic is basing one project on another, as in the 
current discussion, than that's utterly besides the point.

Don't get me wrong, I'm rather sympathetic with the Free Software 
philosophy, and in fact I consider (A)GPL for all my projects. 
But if the fear of tainting a commercial product (such as the DMC 
backend) with code under an incompatible license is a concern, 
then "intrusive" is precisely the right word to describe GPL. 
There is a reason that many bigger companies outright ban it, 
whether that is ultimately a sane thing to do or not.

David
Jan 13 2014
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.01.2014 22:24, schrieb John Colvin:

 On Friday, 10 January 2014 at 21:12:21 UTC, Iain Buclaw wrote:

 On 10 January 2014 21:02, Dwhatever <not real.com> wrote:

 I see LLVM as a better choice because the license is less intrusive.


 That is a rather ignorant assumption.


 I've got some pretty strong sympathies with the gpl, but really? In most
 practical circumstances gpl is on the more restrictive end of common
 open-source licences.


Restrictive to whom?

One reason why my open source code is under GPL, is due to my
experience in projects in the enterprise world, where other more
"free" licenses are taken as free beer and as a mean of avoiding paying 
licenses.

No contribution is ever done, in any form.

--
Paulo
Jan 10 2014
prev sibling next sibling parent reply "Dwhatever" <not real.com> writes:
On Friday, 10 January 2014 at 20:54:06 UTC, John Colvin wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any 
 thread about this. As things has progressed I wonder if 
 Digital Mars DMD should move over to use LLVM instead of its 
 own code generation and compiler framework.

 As I see it with the small amount of contributors D-language 
 has, DMD will never support anything beyond x86 as there are 
 no resources for this. Also, why spend time on recreating the 
 the code generation which has already been done with LLVM? 
 This enables this community to focus on the language which is 
 the most important part as well as supporting more and future 
 processor targets.


 This comes up regularly. It's already been done. Ldc *is* dmd 
 with llvm backend. Gdc is the same idea but with the gcc 
 framework.


Picking LLVM as the default development platform also means that 
it will tested in this environment instead of porting it all the 
time which introduce new bugs. The support is also different 
among the different backends, picking one would harmonize this 
and make it more complete.
Jan 10 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 10 January 2014 at 21:00:47 UTC, Dwhatever wrote:

 On Friday, 10 January 2014 at 20:54:06 UTC, John Colvin wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find 
 any thread about this. As things has progressed I wonder if 
 Digital Mars DMD should move over to use LLVM instead of its 
 own code generation and compiler framework.

 As I see it with the small amount of contributors D-language 
 has, DMD will never support anything beyond x86 as there are 
 no resources for this. Also, why spend time on recreating the 
 the code generation which has already been done with LLVM? 
 This enables this community to focus on the language which is 
 the most important part as well as supporting more and future 
 processor targets.


 This comes up regularly. It's already been done. Ldc *is* dmd 
 with llvm backend. Gdc is the same idea but with the gcc 
 framework.


 Picking LLVM as the default development platform also means 
 that it will tested in this environment instead of porting it 
 all the time which introduce new bugs. The support is also 
 different among the different backends, picking one would 
 harmonize this and make it more complete.



Hopefully, when the ddmd changeover happens (translating the 
frontend to D) the frontend will be truly shared between the 
different compilers.
Jan 10 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 11 January 2014 06:59, Iain Buclaw <ibuclaw gdcproject.org> wrote:


 On 10 January 2014 20:54, John Colvin <john.loughran.colvin gmail.com>
 wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any thread
 about this. As things has progressed I wonder if Digital Mars DMD should
 move over to use LLVM instead of its own code generation and compiler
 framework.

 As I see it with the small amount of contributors D-language has, DMD




 will

 never support anything beyond x86 as there are no resources for this.




 Also,

 why spend time on recreating the the code generation which has already




 been

 done with LLVM? This enables this community to focus on the language




 which

 is the most important part as well as supporting more and future




 processor

 targets.



 This comes up regularly. It's already been done. Ldc *is* dmd with llvm
 backend. Gdc is the same idea but with the gcc framework.


 Indeed. But naturally I'd suggest they move to GCC.  ;-)


Is it possible that GDC will ever produce binaries that will link against
the microsoft libs without problems?
In my experience, GDC produces intrinsic calls to its own runtime all over
the place, and it's not compatible with the microsoft runtime. I also
recall library format mismatch, but that was a long time ago, and I think
we discussed it again since deciding that GDC is now using the same format
as VisualC in windows...?
Can GDC write PDB debuginfo into the objects (CV8 I think it is)?
Jan 10 2014
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 11 January 2014 00:24, Manu <turkeyman gmail.com> wrote:

 On 11 January 2014 06:59, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 10 January 2014 20:54, John Colvin <john.loughran.colvin gmail.com>
 wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any thread
 about this. As things has progressed I wonder if Digital Mars DMD
 should
 move over to use LLVM instead of its own code generation and compiler
 framework.

 As I see it with the small amount of contributors D-language has, DMD
 will
 never support anything beyond x86 as there are no resources for this.
 Also,
 why spend time on recreating the the code generation which has already
 been
 done with LLVM? This enables this community to focus on the language
 which
 is the most important part as well as supporting more and future
 processor
 targets.



 This comes up regularly. It's already been done. Ldc *is* dmd with llvm
 backend. Gdc is the same idea but with the gcc framework.


 Indeed. But naturally I'd suggest they move to GCC.  ;-)



 Is it possible that GDC will ever produce binaries that will link against
 the microsoft libs without problems?
 In my experience, GDC produces intrinsic calls to its own runtime all over
 the place, and it's not compatible with the microsoft runtime. I also recall
 library format mismatch, but that was a long time ago, and I think we
 discussed it again since deciding that GDC is now using the same format as
 VisualC in windows...?
 Can GDC write PDB debuginfo into the objects (CV8 I think it is)?


As I understand, neither GCC nor LLVM are capable of producing PDB.
Has Microsoft even release any documentation or code necessary to
produce files in their PDB format?
Jan 11 2014
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 11 January 2014 at 13:04:13 UTC, Iain Buclaw wrote:

 As I understand, neither GCC nor LLVM are capable of producing 
 PDB.
 Has Microsoft even release any documentation or code necessary 
 to
 produce files in their PDB format?


There are plenty of PDB parsers available, so it should be 
possible to uncover the format from there.

Here's one.

https://code.google.com/p/pdbparse/
Jan 11 2014
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 11 Jan 2014 16:55, "Peter Alexander" <peter.alexander.au gmail.com>
wrote:

 On Saturday, 11 January 2014 at 13:04:13 UTC, Iain Buclaw wrote:

 As I understand, neither GCC nor LLVM are capable of producing PDB.
 Has Microsoft even release any documentation or code necessary to
 produce files in their PDB format?



 There are plenty of PDB parsers available, so it should be possible to


uncover the format from there.

 Here's one.

 https://code.google.com/p/pdbparse/


But just to clarify, that is a reverse engineering effort?
Jan 11 2014
prev sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 11 Jan 2014 05:04:03 -0800, Iain Buclaw <ibuclaw gdcproject.org>  
wrote:


 On 11 January 2014 00:24, Manu <turkeyman gmail.com> wrote:

 On 11 January 2014 06:59, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 10 January 2014 20:54, John Colvin <john.loughran.colvin gmail.com>
 wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any  




 thread

 about this. As things has progressed I wonder if Digital Mars DMD
 should
 move over to use LLVM instead of its own code generation and  




 compiler

 framework.

 As I see it with the small amount of contributors D-language has,  




 DMD

 will
 never support anything beyond x86 as there are no resources for  




 this.

 Also,
 why spend time on recreating the the code generation which has  




 already

 been
 done with LLVM? This enables this community to focus on the language
 which
 is the most important part as well as supporting more and future
 processor
 targets.



 This comes up regularly. It's already been done. Ldc *is* dmd with  


 llvm

 backend. Gdc is the same idea but with the gcc framework.


 Indeed. But naturally I'd suggest they move to GCC.  ;-)



 Is it possible that GDC will ever produce binaries that will link  
 against
 the microsoft libs without problems?
 In my experience, GDC produces intrinsic calls to its own runtime all  
 over
 the place, and it's not compatible with the microsoft runtime. I also  
 recall
 library format mismatch, but that was a long time ago, and I think we
 discussed it again since deciding that GDC is now using the same format  
 as
 VisualC in windows...?
 Can GDC write PDB debuginfo into the objects (CV8 I think it is)?


 As I understand, neither GCC nor LLVM are capable of producing PDB.
 Has Microsoft even release any documentation or code necessary to
 produce files in their PDB format?


This is no longer true of LLVM, they've got Windows specific builds that  
output PDB and link with COFF natively. See: http://llvm.org/builds/

-- 
Adam Wilson
IRC: LightBender
Aurora Project Coordinator
Jan 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 11 January 2014 23:04, Iain Buclaw <ibuclaw gdcproject.org> wrote:


 On 11 January 2014 00:24, Manu <turkeyman gmail.com> wrote:

 On 11 January 2014 06:59, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 10 January 2014 20:54, John Colvin <john.loughran.colvin gmail.com>
 wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any thread
 about this. As things has progressed I wonder if Digital Mars DMD
 should
 move over to use LLVM instead of its own code generation and compiler
 framework.

 As I see it with the small amount of contributors D-language has, DMD
 will
 never support anything beyond x86 as there are no resources for this.
 Also,
 why spend time on recreating the the code generation which has








 already

 been
 done with LLVM? This enables this community to focus on the language
 which
 is the most important part as well as supporting more and future
 processor
 targets.



 This comes up regularly. It's already been done. Ldc *is* dmd with






 llvm

 backend. Gdc is the same idea but with the gcc framework.


 Indeed. But naturally I'd suggest they move to GCC.  ;-)



 Is it possible that GDC will ever produce binaries that will link against
 the microsoft libs without problems?
 In my experience, GDC produces intrinsic calls to its own runtime all


 over

 the place, and it's not compatible with the microsoft runtime. I also


 recall

 library format mismatch, but that was a long time ago, and I think we
 discussed it again since deciding that GDC is now using the same format


 as

 VisualC in windows...?
 Can GDC write PDB debuginfo into the objects (CV8 I think it is)?


 As I understand, neither GCC nor LLVM are capable of producing PDB.
 Has Microsoft even release any documentation or code necessary to
 produce files in their PDB format?


Walter did it for DMD. I think CV8 is more or less documented, but he found
some Microsoft tweaks to the format, or something like that.
Jan 12 2014
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 13 January 2014 05:01, Manu <turkeyman gmail.com> wrote:

 On 11 January 2014 23:04, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 11 January 2014 00:24, Manu <turkeyman gmail.com> wrote:

 On 11 January 2014 06:59, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 10 January 2014 20:54, John Colvin <john.loughran.colvin gmail.com>
 wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any
 thread
 about this. As things has progressed I wonder if Digital Mars DMD
 should
 move over to use LLVM instead of its own code generation and
 compiler
 framework.

 As I see it with the small amount of contributors D-language has,
 DMD
 will
 never support anything beyond x86 as there are no resources for
 this.
 Also,
 why spend time on recreating the the code generation which has
 already
 been
 done with LLVM? This enables this community to focus on the language
 which
 is the most important part as well as supporting more and future
 processor
 targets.



 This comes up regularly. It's already been done. Ldc *is* dmd with
 llvm
 backend. Gdc is the same idea but with the gcc framework.


 Indeed. But naturally I'd suggest they move to GCC.  ;-)



 Is it possible that GDC will ever produce binaries that will link
 against
 the microsoft libs without problems?
 In my experience, GDC produces intrinsic calls to its own runtime all
 over
 the place, and it's not compatible with the microsoft runtime. I also
 recall
 library format mismatch, but that was a long time ago, and I think we
 discussed it again since deciding that GDC is now using the same format
 as
 VisualC in windows...?
 Can GDC write PDB debuginfo into the objects (CV8 I think it is)?


 As I understand, neither GCC nor LLVM are capable of producing PDB.
 Has Microsoft even release any documentation or code necessary to
 produce files in their PDB format?



 Walter did it for DMD. I think CV8 is more or less documented, but he found
 some Microsoft tweaks to the format, or something like that.


Yes, however Walter has *ehem* ties with Microsoft, so he may have
access to information the Free Software community don't. ;)
Jan 13 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-01-13 09:11, Iain Buclaw wrote:


 Yes, however Walter has *ehem* ties with Microsoft, so he may have
 access to information the Free Software community don't. ;)


It doesn't hurt to ask ;)

-- 
/Jacob Carlborg
Jan 13 2014
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 10.01.2014 21:51, schrieb Dwhatever:

 This might have been brought up before but I couldn't find any thread
 about this. As things has progressed I wonder if Digital Mars DMD should
 move over to use LLVM instead of its own code generation and compiler
 framework.

 As I see it with the small amount of contributors D-language has, DMD
 will never support anything beyond x86 as there are no resources for
 this. Also, why spend time on recreating the the code generation which
 has already been done with LLVM? This enables this community to focus on
 the language which is the most important part as well as supporting more
 and future processor targets.


Because Walter wouldn't be able to work on his current job any longer if 
he looks into other compiler vendors source code.

IP laws are always a complicated issue.

--
Paulo
Jan 10 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 10 January 2014 at 21:00:24 UTC, Paulo Pinto wrote:

 Because Walter wouldn't be able to work on his current job any 
 longer if he looks into other compiler vendors source code.

 IP laws are always a complicated issue.


Unless you have an actual explanation as to why this would be the 
case, I'd simply regard this as FUD. I see how the viral nature 
of the GCC license might be a problem for that, but as far as 
LLVM is concerned, Walter would even be able to just rebrand 
Clang as DMC and ship it as a closed-source package. LLVM also 
doesn't require any copyright assignments, which might be an 
impediment for contributing any fixes back to GCC.

David
Jan 11 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On 11.01.2014 12:58, David Nadlinger wrote:

 On Friday, 10 January 2014 at 21:00:24 UTC, Paulo Pinto wrote:

 Because Walter wouldn't be able to work on his current job any longer
 if he looks into other compiler vendors source code.

 IP laws are always a complicated issue.


 Unless you have an actual explanation as to why this would be the case,
 I'd simply regard this as FUD. I see how the viral nature of the GCC
 license might be a problem for that, but as far as LLVM is concerned,
 Walter would even be able to just rebrand Clang as DMC and ship it as a
 closed-source package. LLVM also doesn't require any copyright
 assignments, which might be an impediment for contributing any fixes
 back to GCC.

 David



As far as I remember he already had a few court cases caused by such 
kind of issues.

He is the best person to explain such issues, I would say.

--
Paulo
Jan 11 2014
parent "David Nadlinger" <code klickverbot.at> writes:
On Saturday, 11 January 2014 at 13:16:40 UTC, Paulo Pinto wrote:

 He is the best person to explain such issues, I would say.


…which is precisely why I found it odd that you posted such an 
unqualified umbrella statement here in the first place. ;)

No offense intended, but just speculating about Walter's motives 
doesn't really help the discussion at all.

If I remember correctly, Walter joined the last bigger discussion 
on this issue here on the NG a year ago or so, and licensing 
issues were *not* one of the arguments that lasted.

David
Jan 11 2014
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 11 January 2014 11:58, David Nadlinger <code klickverbot.at> wrote:

 On Friday, 10 January 2014 at 21:00:24 UTC, Paulo Pinto wrote:

 Because Walter wouldn't be able to work on his current job any longer if
 he looks into other compiler vendors source code.

 IP laws are always a complicated issue.



 Unless you have an actual explanation as to why this would be the case, I'd
 simply regard this as FUD. I see how the viral nature of the GCC license
 might be a problem for that, but as far as LLVM is concerned, Walter would
 even be able to just rebrand Clang as DMC and ship it as a closed-source
 package. LLVM also doesn't require any copyright assignments, which might be
 an impediment for contributing any fixes back to GCC.


Remember when I told you that LLVM devs reverted commits made by core
GCC developers because apparently there was no explicit contribution
by them to LLVM?  :-)
Jan 11 2014
parent "David Nadlinger" <code klickverbot.at> writes:
On Saturday, 11 January 2014 at 13:22:52 UTC, Iain Buclaw wrote:

 Remember when I told you that LLVM devs reverted commits made 
 by core
 GCC developers because apparently there was no explicit 
 contribution by them to LLVM?  :-)


I don't recall the details, but I don't see how this is relevant 
to this discussion. There is a difference between requiring 
copyright assignment from contributors and being cautious about 
including code that you suspect to be incompatible with the (more 
liberal) license of your project.

David
Jan 11 2014
prev sibling next sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any 
 thread about this. As things has progressed I wonder if Digital 
 Mars DMD should move over to use LLVM instead of its own code 
 generation and compiler framework.

 As I see it with the small amount of contributors D-language 
 has, DMD will never support anything beyond x86 as there are no 
 resources for this. Also, why spend time on recreating the the 
 code generation which has already been done with LLVM? This 
 enables this community to focus on the language which is the 
 most important part as well as supporting more and future 
 processor targets.


You currently can't get the best of all worlds in a single 
compiler.

LLVM does not support exceptions on native Win32. (Same is true 
for Win64 but I hope to change this.) LLVM does not support 
CodeView debug symbols. Not in the format embedded in object file 
and not as PDB.
In short, you loose the complete native Windows tool chain.

With LDC, you can use other platforms. E.g. it runs on 
Linux/PPC64. But you can't ignore the backend because it has bugs 
and is incomplete.

E.g. on Linux/ARM I have a linker error when I enable generation 
of debug symbols. LLVM for arm-apple-darwin does not support TLS. 
LLVM for PPC supports only 2 of the 4 TLS models. In addition, 
the assembler for PPC/PPC64 does not support all instructions I 
need for std.math.

Regards,
Kai
Jan 11 2014
parent reply Manu <turkeyman gmail.com> writes:
On 12 January 2014 00:35, Kai Nacke <kai redstar.de> wrote:


 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:


 This might have been brought up before but I couldn't find any thread
 about this. As things has progressed I wonder if Digital Mars DMD should
 move over to use LLVM instead of its own code generation and compiler
 framework.

 As I see it with the small amount of contributors D-language has, DMD
 will never support anything beyond x86 as there are no resources for this.
 Also, why spend time on recreating the the code generation which has
 already been done with LLVM? This enables this community to focus on the
 language which is the most important part as well as supporting more and
 future processor targets.


 You currently can't get the best of all worlds in a single compiler.

 LLVM does not support exceptions on native Win32. (Same is true for Win64
 but I hope to change this.) LLVM does not support CodeView debug symbols.
 Not in the format embedded in object file and not as PDB.
 In short, you loose the complete native Windows tool chain.


Is there any progress on any of these things BTW?
At some point, sooner or later, we're REALLY going to need a performance
compiler on Windows...

With LDC, you can use other platforms. E.g. it runs on Linux/PPC64. But you

 can't ignore the backend because it has bugs and is incomplete.

 E.g. on Linux/ARM I have a linker error when I enable generation of debug
 symbols. LLVM for arm-apple-darwin does not support TLS. LLVM for PPC
 supports only 2 of the 4 TLS models. In addition, the assembler for
 PPC/PPC64 does not support all instructions I need for std.math.

 Regards,
 Kai
Jan 12 2014
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:

 On 12 January 2014 00:35, Kai Nacke <kai redstar.de> wrote:


 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:


 This might have been brought up before but I couldn't find 
 any thread
 about this. As things has progressed I wonder if Digital Mars 
 DMD should
 move over to use LLVM instead of its own code generation and 
 compiler
 framework.

 As I see it with the small amount of contributors D-language 
 has, DMD
 will never support anything beyond x86 as there are no 
 resources for this.
 Also, why spend time on recreating the the code generation 
 which has
 already been done with LLVM? This enables this community to 
 focus on the
 language which is the most important part as well as 
 supporting more and
 future processor targets.


 You currently can't get the best of all worlds in a single 
 compiler.

 LLVM does not support exceptions on native Win32. (Same is 
 true for Win64
 but I hope to change this.) LLVM does not support CodeView 
 debug symbols.
 Not in the format embedded in object file and not as PDB.
 In short, you loose the complete native Windows tool chain.


 Is there any progress on any of these things BTW?
 At some point, sooner or later, we're REALLY going to need a 
 performance
 compiler on Windows...


Only recently LLVM developers really started caring about 
Windows, so it will take awhile until LLVM is a first class 
citizen.

http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html

--
Paulo
Jan 12 2014
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:

 On 12 January 2014 00:35, Kai Nacke <kai redstar.de> wrote:


 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:


 This might have been brought up before but I couldn't find 
 any thread
 about this. As things has progressed I wonder if Digital Mars 
 DMD should
 move over to use LLVM instead of its own code generation and 
 compiler
 framework.

 As I see it with the small amount of contributors D-language 
 has, DMD
 will never support anything beyond x86 as there are no 
 resources for this.
 Also, why spend time on recreating the the code generation 
 which has
 already been done with LLVM? This enables this community to 
 focus on the
 language which is the most important part as well as 
 supporting more and
 future processor targets.


 You currently can't get the best of all worlds in a single 
 compiler.

 LLVM does not support exceptions on native Win32. (Same is 
 true for Win64
 but I hope to change this.) LLVM does not support CodeView 
 debug symbols.
 Not in the format embedded in object file and not as PDB.
 In short, you loose the complete native Windows tool chain.


 Is there any progress on any of these things BTW?
 At some point, sooner or later, we're REALLY going to need a 
 performance
 compiler on Windows...


My patch for exceptions on Win64 is finally in review. I hope to 
commit it soon.

The Google guys are adding COFF line number support right now.

Regards,
Kai


 With LDC, you can use other platforms. E.g. it runs on 
 Linux/PPC64. But you

 can't ignore the backend because it has bugs and is incomplete.

 E.g. on Linux/ARM I have a linker error when I enable 
 generation of debug
 symbols. LLVM for arm-apple-darwin does not support TLS. LLVM 
 for PPC
 supports only 2 of the 4 TLS models. In addition, the 
 assembler for
 PPC/PPC64 does not support all instructions I need for 
 std.math.

 Regards,
 Kai
Jan 13 2014
parent reply Manu <turkeyman gmail.com> writes:
On 13 January 2014 21:40, Kai Nacke <kai redstar.de> wrote:


 On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:


 On 12 January 2014 00:35, Kai Nacke <kai redstar.de> wrote:

  On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

  This might have been brought up before but I couldn't find any thread

 about this. As things has progressed I wonder if Digital Mars DMD should
 move over to use LLVM instead of its own code generation and compiler
 framework.

 As I see it with the small amount of contributors D-language has, DMD
 will never support anything beyond x86 as there are no resources for
 this.
 Also, why spend time on recreating the the code generation which has
 already been done with LLVM? This enables this community to focus on the
 language which is the most important part as well as supporting more and
 future processor targets.


 You currently can't get the best of all worlds in a single compiler.

 LLVM does not support exceptions on native Win32. (Same is true for Win64
 but I hope to change this.) LLVM does not support CodeView debug symbols.
 Not in the format embedded in object file and not as PDB.
 In short, you loose the complete native Windows tool chain.


 Is there any progress on any of these things BTW?
 At some point, sooner or later, we're REALLY going to need a performance
 compiler on Windows...


 My patch for exceptions on Win64 is finally in review. I hope to commit it
 soon.

 The Google guys are adding COFF line number support right now.

 Regards,
 Kai



Oooohh yeah, this is exciting! :D
How about Win32? That's really important too, particularly since DMD
doesn't support Win32 :/
Jan 13 2014
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Monday, 13 January 2014 at 12:47:09 UTC, Manu wrote:

 Oooohh yeah, this is exciting! :D
 How about Win32? That's really important too, particularly 
 since DMD
 doesn't support Win32 :/


You mean the 32 bit MSVC toolchain? SEH support is unlikely to 
happen until that Borland patent expires.

David
Jan 13 2014
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 13 January 2014 at 12:47:09 UTC, Manu wrote:

 On 13 January 2014 21:40, Kai Nacke <kai redstar.de> wrote:


 On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:


 On 12 January 2014 00:35, Kai Nacke <kai redstar.de> wrote:

  On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

  This might have been brought up before but I couldn't find 
 any thread

 about this. As things has progressed I wonder if Digital 
 Mars DMD should
 move over to use LLVM instead of its own code generation 
 and compiler
 framework.

 As I see it with the small amount of contributors 
 D-language has, DMD
 will never support anything beyond x86 as there are no 
 resources for
 this.
 Also, why spend time on recreating the the code generation 
 which has
 already been done with LLVM? This enables this community to 
 focus on the
 language which is the most important part as well as 
 supporting more and
 future processor targets.


 You currently can't get the best of all worlds in a single 
 compiler.

 LLVM does not support exceptions on native Win32. (Same is 
 true for Win64
 but I hope to change this.) LLVM does not support CodeView 
 debug symbols.
 Not in the format embedded in object file and not as PDB.
 In short, you loose the complete native Windows tool chain.


 Is there any progress on any of these things BTW?
 At some point, sooner or later, we're REALLY going to need a 
 performance
 compiler on Windows...


 My patch for exceptions on Win64 is finally in review. I hope 
 to commit it
 soon.

 The Google guys are adding COFF line number support right now.

 Regards,
 Kai



 Oooohh yeah, this is exciting! :D
 How about Win32? That's really important too, particularly 
 since DMD
 doesn't support Win32 :/


Genuine question, I have never done any windows specific 
development: Why is Win32 a concern? Where is the overlap between 
requiring Win32 and high performance? Isn't 64 where it's at now?

Is it windows tablets/phones???
Jan 13 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 13 January 2014 at 12:59:53 UTC, John Colvin wrote:

 On Monday, 13 January 2014 at 12:47:09 UTC, Manu wrote:

 On 13 January 2014 21:40, Kai Nacke <kai redstar.de> wrote:


 On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:


 On 12 January 2014 00:35, Kai Nacke <kai redstar.de> wrote:

 On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find 
 any thread

 about this. As things has progressed I wonder if Digital 
 Mars DMD should
 move over to use LLVM instead of its own code generation 
 and compiler
 framework.

 As I see it with the small amount of contributors 
 D-language has, DMD
 will never support anything beyond x86 as there are no 
 resources for
 this.
 Also, why spend time on recreating the the code generation 
 which has
 already been done with LLVM? This enables this community 
 to focus on the
 language which is the most important part as well as 
 supporting more and
 future processor targets.


 You currently can't get the best of all worlds in a single 
 compiler.

 LLVM does not support exceptions on native Win32. (Same is 
 true for Win64
 but I hope to change this.) LLVM does not support CodeView 
 debug symbols.
 Not in the format embedded in object file and not as PDB.
 In short, you loose the complete native Windows tool chain.


 Is there any progress on any of these things BTW?
 At some point, sooner or later, we're REALLY going to need a 
 performance
 compiler on Windows...


 My patch for exceptions on Win64 is finally in review. I hope 
 to commit it
 soon.

 The Google guys are adding COFF line number support right now.

 Regards,
 Kai



 Oooohh yeah, this is exciting! :D
 How about Win32? That's really important too, particularly 
 since DMD
 doesn't support Win32 :/


 Genuine question, I have never done any windows specific 
 development: Why is Win32 a concern? Where is the overlap 
 between requiring Win32 and high performance? Isn't 64 where 
 it's at now?

 Is it windows tablets/phones???


The 64 bit version of Windows API is still called Win32, there 
was no change like the Win16, Win32, Win32s days.

--
Paulo
Jan 13 2014
prev sibling parent "luminousone" <rd.hunt gmail.com> writes:
On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:

 This might have been brought up before but I couldn't find any 
 thread about this. As things has progressed I wonder if Digital 
 Mars DMD should move over to use LLVM instead of its own code 
 generation and compiler framework.

 As I see it with the small amount of contributors D-language 
 has, DMD will never support anything beyond x86 as there are no 
 resources for this. Also, why spend time on recreating the the 
 code generation which has already been done with LLVM? This 
 enables this community to focus on the language which is the 
 most important part as well as supporting more and future 
 processor targets.


LLVM is also the finalizer for HSAIL, AMD is using it for their 
linux port of C++AMP. But I would assume that ldc probably 
wouldn't have any issues generating HSA compatible code with 
minor modifications as is(as the LLVM backend will support it).

I have no idea if GCC will support HSA or not however Microsoft 
is fully supporting it, as is ARM. So I wouldn't think that GCC 
would be to far behind on that one.
Jan 12 2014