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 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
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 next 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 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 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 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 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 "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
prev sibling next sibling parent 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
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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11369dc27819a104efa6df9e
Content-Type: text/plain; charset=UTF-8

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


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


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


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


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


 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)? --001a11369dc27819a104efa6df9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 1 January 2014 06:59, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mailto:i= buclaw gdcproject.org" target=3D"_blank">ibuclaw gdcproject.org</a>&gt;</sp= an> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 1= 0 January 2014 20:54, John Colvin &lt;<a href=3D"mailto:john.loughran.colvi= n gmail.com">john.loughran.colvin gmail.com</a>&gt; wrote:<br> &gt; On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:<br> &gt;&gt;<br> &gt;&gt; This might have been brought up before but I couldn&#39;t find any= thread<br> &gt;&gt; about this. As things has progressed I wonder if Digital Mars DMD = should<br> &gt;&gt; move over to use LLVM instead of its own code generation and compi= ler<br> &gt;&gt; framework.<br> &gt;&gt;<br> &gt;&gt; As I see it with the small amount of contributors D-language has, = DMD will<br> &gt;&gt; never support anything beyond x86 as there are no resources for th= is. Also,<br> &gt;&gt; why spend time on recreating the the code generation which has alr= eady been<br> &gt;&gt; done with LLVM? This enables this community to focus on the langua= ge which<br> &gt;&gt; is the most important part as well as supporting more and future p= rocessor<br> &gt;&gt; targets.<br> &gt;<br> &gt;<br> &gt; This comes up regularly. It&#39;s already been done. Ldc *is* dmd with= llvm<br> &gt; backend. Gdc is the same idea but with the gcc framework.<br> <br> </div></div>Indeed. But naturally I&#39;d suggest they move to GCC. =C2=A0;= -)<br> </blockquote></div><br></div><div class=3D"gmail_extra">Is it possible that= GDC will ever produce binaries that will link against the microsoft libs w= ithout problems?</div><div class=3D"gmail_extra">In my experience, GDC prod= uces intrinsic calls to its own runtime all over the place, and it&#39;s no= t compatible with the microsoft runtime. I also recall library format misma= tch, 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...?</d= iv> <div class=3D"gmail_extra">Can GDC write PDB debuginfo into the objects (CV= 8 I think it is)?</div></div> --001a11369dc27819a104efa6df9e--
Jan 10 2014
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling 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 "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 next sibling parent "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
prev sibling next 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 next sibling parent "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
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
--047d7bdc17a628973004efb5d08d
Content-Type: text/plain; charset=ISO-8859-1

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

 Here's one.

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

But just to clarify, that is a reverse engineering effort? --047d7bdc17a628973004efb5d08d Content-Type: text/html; charset=ISO-8859-1 <p dir="ltr">On 11 Jan 2014 16:55, &quot;Peter Alexander&quot; &lt;<a href="mailto:peter.alexander.au gmail.com">peter.alexander.au gmail.com</a>&gt; wrote:<br> &gt;<br> &gt; On Saturday, 11 January 2014 at 13:04:13 UTC, Iain Buclaw wrote:<br> &gt;&gt;<br> &gt;&gt; As I understand, neither GCC nor LLVM are capable of producing PDB.<br> &gt;&gt; Has Microsoft even release any documentation or code necessary to<br> &gt;&gt; produce files in their PDB format?<br> &gt;<br> &gt;<br> &gt; There are plenty of PDB parsers available, so it should be possible to uncover the format from there.<br> &gt;<br> &gt; Here&#39;s one.<br> &gt;<br> &gt; <a href="https://code.google.com/p/pdbparse/">https://code.google.com/p/pdbparse/</a></p> <p dir="ltr">But just to clarify, that is a reverse engineering effort?</p> --047d7bdc17a628973004efb5d08d--
Jan 11 2014
prev sibling next 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  


 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  


 framework.

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


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


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


 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

 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 "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c1bce8bd0bca04efd2f91b
Content-Type: text/plain; charset=UTF-8

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




 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



 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

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

 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

 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. --001a11c1bce8bd0bca04efd2f91b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 1 January 2014 23:04, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mailto:i= buclaw gdcproject.org" target=3D"_blank">ibuclaw gdcproject.org</a>&gt;</sp= an> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 1= 1 January 2014 00:24, Manu &lt;<a href=3D"mailto:turkeyman gmail.com">turke= yman gmail.com</a>&gt; wrote:<br> &gt; On 11 January 2014 06:59, Iain Buclaw &lt;<a href=3D"mailto:ibuclaw gd= cproject.org">ibuclaw gdcproject.org</a>&gt; wrote:<br> &gt;&gt;<br> &gt;&gt; On 10 January 2014 20:54, John Colvin &lt;<a href=3D"mailto:john.l= oughran.colvin gmail.com">john.loughran.colvin gmail.com</a>&gt;<br> &gt;&gt; wrote:<br> &gt;&gt; &gt; On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:<= br> &gt;&gt; &gt;&gt;<br> &gt;&gt; &gt;&gt; This might have been brought up before but I couldn&#39;t= find any thread<br> &gt;&gt; &gt;&gt; about this. As things has progressed I wonder if Digital = Mars DMD<br> &gt;&gt; &gt;&gt; should<br> &gt;&gt; &gt;&gt; move over to use LLVM instead of its own code generation = and compiler<br> &gt;&gt; &gt;&gt; framework.<br> &gt;&gt; &gt;&gt;<br> &gt;&gt; &gt;&gt; As I see it with the small amount of contributors D-langu= age has, DMD<br> &gt;&gt; &gt;&gt; will<br> &gt;&gt; &gt;&gt; never support anything beyond x86 as there are no resourc= es for this.<br> &gt;&gt; &gt;&gt; Also,<br> &gt;&gt; &gt;&gt; why spend time on recreating the the code generation whic= h has already<br> &gt;&gt; &gt;&gt; been<br> &gt;&gt; &gt;&gt; done with LLVM? This enables this community to focus on t= he language<br> &gt;&gt; &gt;&gt; which<br> &gt;&gt; &gt;&gt; is the most important part as well as supporting more and= future<br> &gt;&gt; &gt;&gt; processor<br> &gt;&gt; &gt;&gt; targets.<br> &gt;&gt; &gt;<br> &gt;&gt; &gt;<br> &gt;&gt; &gt; This comes up regularly. It&#39;s already been done. Ldc *is*= dmd with llvm<br> &gt;&gt; &gt; backend. Gdc is the same idea but with the gcc framework.<br> &gt;&gt;<br> &gt;&gt; Indeed. But naturally I&#39;d suggest they move to GCC. =C2=A0;-)<= br> &gt;<br> &gt;<br> &gt; Is it possible that GDC will ever produce binaries that will link agai= nst<br> &gt; the microsoft libs without problems?<br> &gt; In my experience, GDC produces intrinsic calls to its own runtime all = over<br> &gt; the place, and it&#39;s not compatible with the microsoft runtime. I a= lso recall<br> &gt; library format mismatch, but that was a long time ago, and I think we<= br> &gt; discussed it again since deciding that GDC is now using the same forma= t as<br> &gt; VisualC in windows...?<br> &gt; Can GDC write PDB debuginfo into the objects (CV8 I think it is)?<br> <br> </div></div>As I understand, neither GCC nor LLVM are capable of producing = PDB.<br> Has Microsoft even release any documentation or code necessary to<br> produce files in their PDB format?<br> </blockquote></div><br></div><div class=3D"gmail_extra">Walter did it for D= MD. I think CV8 is more or less documented, but he found some Microsoft twe= aks to the format, or something like that.</div></div> --001a11c1bce8bd0bca04efd2f91b--
Jan 12 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b5d2ea4081bb104efd303c8
Content-Type: text/plain; charset=UTF-8

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

--047d7b5d2ea4081bb104efd303c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 January 2014 00:35, Kai Nacke <span dir=3D"ltr">&lt;<a href=3D"mailto:kai= redstar.de" target=3D"_blank">kai redstar.de</a>&gt;</span> wrote:<br><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <div class=3D"im">On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wro= te:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> This might have been brought up before but I couldn&#39;t find any thread a= bout this. As things has progressed I wonder if Digital Mars DMD should mov= e over to use LLVM instead of its own code generation and compiler framewor= k.<br> <br> 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 bee= n done with LLVM? This enables this community to focus on the language whic= h is the most important part as well as supporting more and future processo= r targets.<br> </blockquote> <br></div> You currently can&#39;t get the best of all worlds in a single compiler.<br=

LLVM does not support exceptions on native Win32. (Same is true for Win64 b= ut I hope to change this.) LLVM does not support CodeView debug symbols. No= t in the format embedded in object file and not as PDB.<br> In short, you loose the complete native Windows tool chain.<br></blockquote=
<div><br></div><div>Is there any progress on any of these things BTW?</div=
<div>At some point, sooner or later, we&#39;re REALLY going to need a perf=

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> With LDC, you can use other platforms. E.g. it runs on Linux/PPC64. But you= can&#39;t ignore the backend because it has bugs and is incomplete.<br> <br> E.g. on Linux/ARM I have a linker error when I enable generation of debug s= ymbols. LLVM for arm-apple-darwin does not support TLS. LLVM for PPC suppor= ts only 2 of the 4 TLS models. In addition, the assembler for PPC/PPC64 doe= s not support all instructions I need for std.math.<br> <br> Regards,<br> Kai<br> </blockquote></div><br></div></div> --047d7b5d2ea4081bb104efd303c8--
Jan 12 2014
prev sibling 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 next sibling parent "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
prev sibling next sibling parent 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
prev sibling 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 "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e015388f65f514a04efd9788c
Content-Type: text/plain; charset=UTF-8

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.

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.

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 :/ --089e015388f65f514a04efd9788c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 3 January 2014 21:40, Kai Nacke <span dir=3D"ltr">&lt;<a href=3D"mailto:kai= redstar.de" target=3D"_blank">kai redstar.de</a>&gt;</span> wrote:<br><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <div class=3D"im">On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:<b= r> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 12 January 2014 00:35, Kai Nacke &lt;<a href=3D"mailto:kai redstar.de" t= arget=3D"_blank">kai redstar.de</a>&gt; wrote:<br> <br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> This might have been brought up before but I couldn&#39;t find any thread<b= r> about this. As things has progressed I wonder if Digital Mars DMD should<br=

framework.<br> <br> As I see it with the small amount of contributors D-language has, DMD<br> will never support anything beyond x86 as there are no resources for this.<= br> Also, why spend time on recreating the the code generation which has<br> already been done with LLVM? This enables this community to focus on the<br=


<br> </blockquote> <br> You currently can&#39;t get the best of all worlds in a single compiler.<br=

LLVM does not support exceptions on native Win32. (Same is true for Win64<b= r> but I hope to change this.) LLVM does not support CodeView debug symbols.<b= r> Not in the format embedded in object file and not as PDB.<br> In short, you loose the complete native Windows tool chain.<br> <br> </blockquote> <br></div><div class=3D"im"> Is there any progress on any of these things BTW?<br> At some point, sooner or later, we&#39;re REALLY going to need a performanc= e<br> compiler on Windows...<br> </div></blockquote> <br> My patch for exceptions on Win64 is finally in review. I hope to commit it = soon.<br> <br> The Google guys are adding COFF line number support right now.<br> <br> Regards,<br> Kai</blockquote><div><br></div><div>Oooohh yeah, this is exciting! :D</div>= <div>How about Win32? That&#39;s really important too, particularly since D= MD doesn&#39;t support Win32 :/</div></div></div></div> --089e015388f65f514a04efd9788c--
Jan 13 2014
prev sibling 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 next sibling parent "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.

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.

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
prev sibling next sibling 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.

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.

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 "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