https://github.com/llvm-mirror/llvm/tree/svn-tags/RELEASE_27...
LLILC – LLVM-Based Compiler for .NET CoreCLR
41–44 of 44 posts
Re: LLILC – LLVM-Based Compiler for .NET CoreCLR
#42Mailing list post: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084459... And also check out LLVMSharp -- http://www.llvmsharp.org which gives LLVM access to .NET Disclaimer: I'm involved in both projects.
LLVMSharp provides C# bindings to LLVM's C interface. It does not allow LLVM projects to use dotnet code.
Re: LLILC – LLVM-Based Compiler for .NET CoreCLR
#43It seems the pace of .Net improvement is moving much faster then the JVM land. What are the chances of Enterprise switching to .Net instead of Java?
It depends on what you count as JVM land, I'd say. If you live in JVM land and value modern development you are probably already on Groovy, Gradle and Grails - where Grails imo. is ahead of the MVC4/5/6 stack...
* scripting to manipulate Java classes, for testing and 50-line scripts in Gradle, though Gradle's been opening up its API so any JVM language can use it. When Java 8 becomes more widespread, a future version of Gradle might standardize on Java lambdas and ignore use of Groovy closures in its DSL
* the MOP used by Grails, though Grails is following its namesake Rails into obscurity
Although Groovy 2 bundled a statically-typed compiler to compete with Java, virtually no-one uses it. There's far better choices for developers who want to replace Java on the JVM, such as Scala. Groovy really should've stuck to its dynamic roots and niche by adding scripting support for Scala-compiled classes instead of going into head on competition with it and Java.
Re: LLILC – LLVM-Based Compiler for .NET CoreCLR
#44Earlier quoted context omitted.
Not sure we're talking about the same thing. To my knowledge no other ecosystem has anything close to Graal and Truffle at this point, much less "since day 1" of .NET. The closest thing I can think of is PyPy, which like Graal+Truffle lets you write a dynamic language in a high-level way, but still get specialized JIT compilation "for free". (In PyPy you write an interpreter, in Graal+Truffle it's more declarative.)…
As I understand it, Graal+Truffle is basically the DLR. This has been around since 2008 from Microsoft. Both IronPython and IronRuby have used this for years. The "Day 1" comment was specifically pointed at the read-between the lines for Graal, which is basically to create a real IL for Java instead of using the InvokeDynamic semantic that is currently envogue for Scala, Clojure, etc. .NET has had the multi-language…