• bearophile <bearophileHUGS lycos.com> Jul 14 2009
• Bill Baxter <wbaxter gmail.com> Jul 14 2009
• Leandro Lucarella <llucax gmail.com> Jul 14 2009
• bearophile <bearophileHUGS lycos.com> Jul 14 2009
• Christian Kamm <check ldc-commits.com> Jul 15 2009
• Don <nospam nospam.com> Jul 15 2009
• Christian Kamm <check ldc-commits.com> Jul 15 2009
• Tomas Lindquist Olsen <tomas.l.olsen gmail.com> Jul 15 2009

bearophile <bearophileHUGS lycos.com> writes:

Robert Clipsham:
What exactly is it you mean by this?<


I keep saying wrong things every day, so this too can be wrong.

DMD back-end is not bad, it compiles quite quickly, and there are many tests
where the binary it produces is a bit faster than the binary produced by LDC.

But LLVM offers many interesting things that are hard to do with DMD's
back-end, often such things are already implemented in LLVM (maybe not fully
refined yet, but they are working on it) and they are waiting to be used. I'm
looking at the linker too, for example with LDC you can do advanced Link-time
optimizations, and in future it will probably be able to do even more things
(like reducing code bloat produced by templates).

On the other hand few things done by DMD are hard to do with LLVM.
So I think D development/developers have to take a more serious look at LLVM,
and to design D2 thinking that LLVM and its qualities may be available. A
language like D must not be designed to work on LLVM only; but ignoring what
LLVM offers, and limiting the D design just to what is able to do today the DMD
backend, is not right.

If D will become widespread, four years from now people will probably use LDC
more than DMD, so designing D around the limits of DMD doesn't sound right.

In another post I have listed part of the things offered by LLVM, for example
it can compile pieces of code dynamically at runtime, and the compiler can be
used as a collection of tools to compile code, etc. Such feature was refused by
Walter also because it's hard/long to implement (on DMD). But if it's available
then it may be better to think what can be done with LLVM.

Bye,
bearophile

Bill Baxter <wbaxter gmail.com> writes:

On Tue, Jul 14, 2009 at 1:37 PM, bearophile<bearophileHUGS lycos.com> wrote=
:
 Robert Clipsham:


 But LLVM offers many interesting things that are hard to do with DMD's ba=


refined yet, but they are working on it) and they are waiting to be used. I=
'm looking at the linker too, for example with LDC you can do advanced Link=
-time optimizations, and in future it will probably be able to do even more=
 things (like reducing code bloat produced by templates).
 On the other hand few things done by DMD are hard to do with LLVM.


Except for generating exceptions on Windows, apparently.

I agree with you generally though.

--bb

Leandro Lucarella <llucax gmail.com> writes:

bearophile, el 14 de julio a las 16:37 me escribiste:
 Robert Clipsham:
What exactly is it you mean by this?<


 I keep saying wrong things every day, so this too can be wrong.
 
 DMD back-end is not bad, it compiles quite quickly, and there are many
 tests where the binary it produces is a bit faster than the binary
 produced by LDC.
 
 But LLVM offers many interesting things that are hard to do with DMD's
 back-end, often such things are already implemented in LLVM (maybe not
 fully refined yet, but they are working on it) and they are waiting to
 be used. I'm looking at the linker too, for example with LDC you can do
 advanced Link-time optimizations, and in future it will probably be able
 to do even more things (like reducing code bloat produced by templates).
 
 On the other hand few things done by DMD are hard to do with LLVM.  So
 I think D development/developers have to take a more serious look at
 LLVM, and to design D2 thinking that LLVM and its qualities may be
 available. A language like D must not be designed to work on LLVM only;
 but ignoring what LLVM offers, and limiting the D design just to what is
 able to do today the DMD backend, is not right.
 
 If D will become widespread, four years from now people will probably
 use LDC more than DMD, so designing D around the limits of DMD doesn't
 sound right.
 
 In another post I have listed part of the things offered by LLVM, for
 example it can compile pieces of code dynamically at runtime, and the
 compiler can be used as a collection of tools to compile code, etc. Such
 feature was refused by Walter also because it's hard/long to implement
 (on DMD). But if it's available then it may be better to think what can
 be done with LLVM.


And most of that list where just optimizations, that nothing had to do
with the language. I think you have no point on this one (even when I do
strongly believe that LDC can be a much better compiler than DMD and LLVM
is a great backend).

And even for things that are relevant to the language, I don't think
D should be attached to *any* backend, not DMD, not LLVM. Things required
by the specification should be doable in any backend if you plan to see
more compilers in the future.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Los jóvenes no son solo brazos que nos cargan... También se los puede
mandar a la guerra, que es su obligación.
	-- Ricardo Vaporeso

bearophile <bearophileHUGS lycos.com> writes:

Leandro Lucarella:
 And even for things that are relevant to the language, I don't think
 D should be attached to *any* backend, not DMD, not LLVM. Things required
 by the specification should be doable in any backend if you plan to see
 more compilers in the future.


I agree that restricting D to just the single LLVM is bad, but doing the
opposite too is bad: if you look just for the greatest common divisor among
back-ends then you probably have to remove from the D specs the "real" type,
because I think GCC can't implement them well. So some compromise have to be
found.
And generally having a good open-source reference implementation of a language
is better than having three weak implementations (some dynamic languages
survive fine for years with just one reference implementation, and they often
don't even have formal specs).

Bye,
bearophile

Christian Kamm <check ldc-commits.com> writes:

bearophile Wrote:
 - making D2 fitter for the LLVM back-end;


I do not think this is necessary. LDC can implement most 
of D1 just fine on top of LLVM. The omissions are minor:
http://www.dsource.org/projects/ldc/wiki/Docs#Violationsofthespecification

Exposing particular features of the backend to the user 
should be done through compiler-specific extensions. See
http://www.dsource.org/projects/ldc/wiki/InlineAsmExpressions
for an example.

Otherwise you'll make implementing a correct backend
for D even harder.

Don <nospam nospam.com> writes:

Christian Kamm wrote:
 bearophile Wrote:
 - making D2 fitter for the LLVM back-end;


 I do not think this is necessary. LDC can implement most 
 of D1 just fine on top of LLVM. The omissions are minor:
 http://www.dsource.org/projects/ldc/wiki/Docs#Violationsofthespecification
 
 Exposing particular features of the backend to the user 
 should be done through compiler-specific extensions. See
 http://www.dsource.org/projects/ldc/wiki/InlineAsmExpressions
 for an example.
 
 Otherwise you'll make implementing a correct backend
 for D even harder.
 


It's the other way around. We need to remove the places where DMD's 
backend is exposed in the language. It's reassuring that LDC has been 
made without finding many such cases.

Christian Kamm <check ldc-commits.com> writes:

Don Wrote:
 It's the other way around. We need to remove the places where DMD's 
 backend is exposed in the language. It's reassuring that LDC has been 
 made without finding many such cases.


I agree. From my point of view naked functions and inline assembly - and 
the associated assumption that we have direct control over the emitted 
assembly - have caused the most issues. It seems to be appropriate for D 
though.

There's also the D calling convention; we've pretty much got it covered
now, but there's a reason GDC still uses the C one instead.

Finally, some of the semantic checking in DMD is done in the backend 
instead of the frontend. These have always caused trouble until
we patched the frontend or inserted similar checking into our own
backend code. Unfortunately we haven't kept a list of these around
(or opened tickets for them).

Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:

On Tue, Jul 14, 2009 at 11:12 PM, Bill Baxter<wbaxter gmail.com> wrote:
 On Tue, Jul 14, 2009 at 1:37 PM, bearophile<bearophileHUGS lycos.com> wro=


 Robert Clipsham:


 But LLVM offers many interesting things that are hard to do with DMD's b=




 refined yet, but they are working on it) and they are waiting to be used. =
I'm looking at the linker too, for example with LDC you can do advanced Lin=
k-time optimizations, and in future it will probably be able to do even mor=
e things (like reducing code bloat produced by templates).
 On the other hand few things done by DMD are hard to do with LLVM.


 Except for generating exceptions on Windows, apparently.


LLVM is getting better support for SJLJ exception handling. This would
get us to the same point GCC is at.

I think the bigger problem is lack of documentation on SEH and the
runtime support Windows provides for it. There has even been some
mailing list threads about it on LLVMDev recently... I think the best
solution will be to use Dwarf on Windows eventually as well (which
also seems to be the route GCC is going).

I'm not sure how Walter figured these things out ?

 I agree with you generally though.

 --bb