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

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.

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