www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Google techtalk on LLVM 2.0 and cfront

reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
http://video.google.com/videoplay?docid=1921156852099786640
Aug 21 2007
next sibling parent Stephen Waits <steve waits.net> writes:
Knud Soerensen wrote:

 http://video.google.com/videoplay?docid=1921156852099786640


Thanks for the link.  I know at least a few folks (posted in D.gnu) have 
been working on grafting the D front end onto LLVM.

--Steve
Aug 21 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Knud Soerensen wrote:

 http://video.google.com/videoplay?docid=1921156852099786640


LLVM looks very cool.
At one point in that talk he says that LLVM isn't trying to replace GCC, 
that they have different, though partially overlapping goals, and that 
GCC does some things that LLVM will never do as well as GCC.

I'm curious what things he was referring to.  It seems to me from his 
presentation that LLVM(+clang) is very much aiming to replace GCC.  Or 
at least become the backbone for a next-gen GCC.  Why should he not want 
to own up to that?  He even goes on to spend a bunch of slides comparing 
performance of LLVM+clang to GCC.

But enough of that.

After watching that presentation I became pretty convinced that the 
future of D should be LLVM.  They're making exactly the sort of 
library-based compiler I was talking about not too long ago.  A library 
that will enable not just compiling but also give access to the AST for 
things like source code highlighting and source-code translation and 
code generation tools.

Most of that functionality is actually going into clang, which he pretty 
much said flat out would not support anything besides C,C++ and ObjC. 
But there must be a lot of code that could be leveraged there, and if 
nothing else following the general library-centric design of clang would 
probably be a good thing.  That said it seems like clang is still in the 
very early stages and is no where near being a real C front end yet, let 
alone a C++ front end.

--bb
Aug 22 2007
next sibling parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
Bill Baxter wrote:

 Knud Soerensen wrote:

 http://video.google.com/videoplay?docid=1921156852099786640


 
 LLVM looks very cool.
 At one point in that talk he says that LLVM isn't trying to replace GCC, 
 that they have different, though partially overlapping goals, and that 
 GCC does some things that LLVM will never do as well as GCC.


i got the feeling that this was a political statement :)
they probably didn't intend to kill GCC, but they could, by accident.


 After watching that presentation I became pretty convinced that the 
 future of D should be LLVM.


absolutely. i'm sure it won't be too long until he first llvm based D 
compiler surfaces.


 Most of that functionality is actually going into clang, which he pretty 
 much said flat out would not support anything besides C,C++ and ObjC. 
 But there must be a lot of code that could be leveraged there, and if 
 nothing else following the general library-centric design of clang would 
 probably be a good thing.  That said it seems like clang is still in the 
 very early stages and is no where near being a real C front end yet, let 
 alone a C++ front end.


using clang to write a D frontend may not the best idea anyway. D can be 
parsed a lot easier than C based languages. it might be more work to 
integrate with clang than to write the frontend from scratch.
Aug 23 2007
parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Jascha Wetzel wrote:

 i'm sure it won't be too long until he first llvm based D compiler surfaces.


I watched the talk, was inspired, and about an hour later began to write a D
frontend for LLVM, in D. <g>. I'm basing it on the clang source but I'm writing
everything from scratch. One plus is that I can do away with a bunch of stuff
that isn't needed, such as the preprocessor.

I'll let people know if it gets to the point where it's of some use. It can't
even be compiled yet.

-- 
Remove ".doesnotlike.spam" from the mail address.
Aug 23 2007
next sibling parent Jascha Wetzel <"[firstname]" mainia.de> writes:
Deewiant wrote:

 Jascha Wetzel wrote:

 i'm sure it won't be too long until he first llvm based D compiler surfaces.


 
 I watched the talk, was inspired, and about an hour later began to write a D
 frontend for LLVM, in D. <g>. I'm basing it on the clang source but I'm writing
 everything from scratch. One plus is that I can do away with a bunch of stuff
 that isn't needed, such as the preprocessor.
 
 I'll let people know if it gets to the point where it's of some use. It can't
 even be compiled yet.
 


:) i might be tempted to add a codegen to SEATD's D parsers some time, 
too...
Aug 23 2007
prev sibling parent reply Stephen Waits <steve waits.net> writes:
Deewiant wrote:

 Jascha Wetzel wrote:

 i'm sure it won't be too long until he first llvm based D compiler surfaces.


 
 I watched the talk, was inspired, and about an hour later began to write a D
 frontend for LLVM, in D. <g>. I'm basing it on the clang source but I'm writing


Tomas Lindquis Olsen has mentioned that he's working on this.  Check out 
the LLVM thread over in D.gnu entitled "D + LLVM?".

--Steve
Aug 23 2007
parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Stephen Waits wrote:

 Deewiant wrote:

 I watched the talk, was inspired, and about an hour later began to write a
 D frontend for LLVM, in D. <g>. I'm basing it on the clang source but I'm
 writing


 
 Tomas Lindquis Olsen has mentioned that he's working on this.  Check out the
 LLVM thread over in D.gnu entitled "D + LLVM?".
 


I know. The difference is that he's using the DMD frontend whereas I'm writing
one from scratch.

The idea is that if I don't (read: since I won't) get to the codegen phase any
time soon, it should at least be usable as a "lint"-like tool for D, providing
better diagnostics than DMD. Probably also metadata for other tools like IDEs,
as was mentioned in the talk.

-- 
Remove ".doesnotlike.spam" from the mail address.
Aug 24 2007
parent reply BLS <nanali nospam-wanadoo.fr> writes:
Deewiant schrieb:

 Stephen Waits wrote:

 Deewiant wrote:

 I watched the talk, was inspired, and about an hour later began to write a
 D frontend for LLVM, in D. <g>. I'm basing it on the clang source but I'm
 writing


 Tomas Lindquis Olsen has mentioned that he's working on this.  Check out the
 LLVM thread over in D.gnu entitled "D + LLVM?".


 
 I know. The difference is that he's using the DMD frontend whereas I'm writing
 one from scratch.
 
 The idea is that if I don't (read: since I won't) get to the codegen phase any
 time soon, it should at least be usable as a "lint"-like tool for D, providing
 better diagnostics than DMD. Probably also metadata for other tools like IDEs,
 as was mentioned in the talk.
 


Why reinventing the wheel ?
http://code.google.com/p/dil/
Quote :

dil is a hand-crafted compiler implementation for the D programming 
language. Currently the lexer and the parser are fully implemented 
(except for very minor things.) No semantic analysis is done at the 
moment. The backend will most probably be gcc.

What dil can do at the moment:

     * dil is fully internationalized and can output compiler messages 
in English, German and Turkish. You can determine which language to use 
with a setting in config.d.
     * Generate XML or HTML documents. You can choose to generate tags 
for tokens only or you can also have the whole parse tree unparsed. The 
whitespace of the original source file is preserved. You can view the 
HTML documents in any browser you like. The XML documents can only be 
viewed in W3C-standards compatible browsers(*) in combination with an 
XML formatting CSS document. dil provides two ordinary CSS documents 
(for XML/HTML) which can be customized to one's heart's content. (*Note: 
Internet Explorer is the only browser that spectacularly fails at this 
job.)

     * dil can parse D 2.0 additions:
           o ForeachRangeStatement.
           o Cast expressions: cast(const) and cast(invariant).
           o Type constructors: const(Type) and invariant(Type).
           o Traits expressions: __traits(Identifier) and 
__traits(Identifier, TemplateArguments).
           o const/invariant/final/scope/static as storage classes in 
parameter lists (e.g. void func(final scope Foo f);).
           o invariant as storage class for declarations (e.g. invariant 
Foo f;).

End Quote
HTH Bjoern
Aug 25 2007
parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
BLS wrote:

 Why reinventing the wheel ?


So that I can stop saying IANACW. ;-)

In the end, if I'm going to write the codegen part of the frontend it's best if
I know the code in and out. And the best way to do that is to write it myself,
then rewrite it.


 http://code.google.com/p/dil/


Looks good. Too bad it's GPLv3.

-- 
Remove ".doesnotlike.spam" from the mail address.
Aug 26 2007
next sibling parent reply "Aziz K." <aziz.kerim gmail.com> writes:
 http://code.google.com/p/dil/


 Looks good. Too bad it's GPLv3.


Why is this bad? Would you like to link non-GPL3 code against dil? I'd  
consider changing the license if somebody would like to do that...
Aug 26 2007
parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Aziz K. wrote:

 http://code.google.com/p/dil/


 Looks good. Too bad it's GPLv3.


 
 Why is this bad? Would you like to link non-GPL3 code against dil? I'd
 consider changing the license if somebody would like to do that...


I'm going to write my frontend in any case. If yours ends up better/more
popular, good for you: I might end up contributing to it. <g>

But I don't like the GPLv3 (the "tivoization" stuff), and will probably release
my frontend code as LGPLv2. I haven't gone over the details, but what I'm after
is the benefits of GPL without the restriction that you can't link to non-free
code, and I think that's what the LGPL is for.

This also prevents me from actually looking in too much detail at your code:
it's possible that some jerk decides that I'm stealing your code and placing it
in my project. I could then be sued for not having my code under GPLv3.
(Actually, I'm not sure to what extent third parties can do that. I trust you
not to.)

In summary: IANAL, but I try to be careful, and I don't like the GPLv3.

-- 
Remove ".doesnotlike.spam" from the mail address.
Aug 26 2007
prev sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Deewiant schrieb:

 BLS wrote:

 Why reinventing the wheel ?


 
 So that I can stop saying IANACW. ;-)


What the heck is IANACW ?

 
 In the end, if I'm going to write the codegen part of the frontend it's best if
 I know the code in and out. And the best way to do that is to write it myself,
 then rewrite it.


IMO Aziz's code is pretty clean and readable.


 

 http://code.google.com/p/dil/


 
 Looks good. Too bad it's GPLv3.
 


See Aziz's message
Aug 26 2007
parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
BLS wrote:

 Deewiant schrieb:

 BLS wrote:

 Why reinventing the wheel ?


 So that I can stop saying IANACW. ;-)


 
 What the heck is IANACW ?


"I am not a compiler writer."

-- 
Remove ".doesnotlike.spam" from the mail address.
Aug 26 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:

 Knud Soerensen wrote:

 http://video.google.com/videoplay?docid=1921156852099786640


 
 LLVM looks very cool.
 At one point in that talk he says that LLVM isn't trying to replace GCC, 
 that they have different, though partially overlapping goals, and that 
 GCC does some things that LLVM will never do as well as GCC.
 
 I'm curious what things he was referring to.  It seems to me from his 
 presentation that LLVM(+clang) is very much aiming to replace GCC.  Or 
 at least become the backbone for a next-gen GCC.  Why should he not want 
 to own up to that?  He even goes on to spend a bunch of slides comparing 
 performance of LLVM+clang to GCC.
 
 But enough of that.
 
 After watching that presentation I became pretty convinced that the 
 future of D should be LLVM.  They're making exactly the sort of 
 library-based compiler I was talking about not too long ago.  A library 
 that will enable not just compiling but also give access to the AST for 
 things like source code highlighting and source-code translation and 
 code generation tools.
 


I watched that presentation, and found it very interesting (and very 
smart) that one of the goals of LLVM was to provided an AST useful not 
just for compilation, but also for code analysis tools, including 
*interactive* code analysis tools, like IDEs (which he specificaly 
mentioned several times).
If DMD's AST had such usage in mind as well, it would be saving us IDE 
developers a lot of time and effort.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 23 2007
parent Tristam MacDonald <swiftcoder gmail.com> writes:
Also worth looking at re D is the HLVM (http://hlvm.org/), a little know 
front-end toolkit for LLVM. it is intended to make the work of building 
the compiler front-end as painless as LLVM does for the back-end. Sadly, 
it isn't very active at the moment, but perhaps with a little TLC...

Bruno Medeiros wrote:

 Bill Baxter wrote:

 Knud Soerensen wrote:

 http://video.google.com/videoplay?docid=1921156852099786640


 LLVM looks very cool.
 At one point in that talk he says that LLVM isn't trying to replace 
 GCC, that they have different, though partially overlapping goals, and 
 that GCC does some things that LLVM will never do as well as GCC.

 I'm curious what things he was referring to.  It seems to me from his 
 presentation that LLVM(+clang) is very much aiming to replace GCC.  Or 
 at least become the backbone for a next-gen GCC.  Why should he not 
 want to own up to that?  He even goes on to spend a bunch of slides 
 comparing performance of LLVM+clang to GCC.

 But enough of that.

 After watching that presentation I became pretty convinced that the 
 future of D should be LLVM.  They're making exactly the sort of 
 library-based compiler I was talking about not too long ago.  A 
 library that will enable not just compiling but also give access to 
 the AST for things like source code highlighting and source-code 
 translation and code generation tools.


 
 I watched that presentation, and found it very interesting (and very 
 smart) that one of the goals of LLVM was to provided an AST useful not 
 just for compilation, but also for code analysis tools, including 
 *interactive* code analysis tools, like IDEs (which he specificaly 
 mentioned several times).
 If DMD's AST had such usage in mind as well, it would be saving us IDE 
 developers a lot of time and effort.
Aug 23 2007