11–20 of 20 posts
Looks like this is from The Architecture of Open Source Applications: http://www.aosabook.org/en/llvm.html There's some other good stuff (and a book) on the site as well.
Author forgets to mention the more recent "success" story of compiling languages to Javascript. That is a shame for the industry that such thing exists.
http://www.aosabook.org/en/llvm.html>
AOSA is now a two-volume book " rel="nofollow">http://www.aosabook.org>, with chapters providing overviews of 49 open source projects.
This article has a lot of interesting stuff, though it tends to be largely cheerleading LLVM's design decisions, rather than delving into the really interesting tradeoffs. For example, some compilers use multiple levels of optimizer IR, for example Open64/Pathscale. This allows them to perform more high-level language-specific optimizations. LLVM forces front-ends to lower their code directly down to its fairly low l…
I spent a couple years working on a .NET runtime that used LLVM as its back-end and found it to be more than adequate as a base for that ecosystem, specifically languages like C# and C++-CLI. Some changes were needed to LLVM in order to support precise garbage collection but they were fairly minimal. Debugging worked very well, though it wasn't as full featured as Visual Studio's .NET debugging environment it was abo…
The original source for this LLVM article is a chapter in the Architecture of Open Source Applications (AOSA), and the LLVM chapter is available at: http://www.aosabook.org/en/llvm.html> ; AOSA is now a two-volume book " rel="nofollow">http://www.aosabook.org> , with chapters providing overviews of 49 open source projects.
Earlier quoted context omitted.
I spent a couple years working on a .NET runtime that used LLVM as its back-end and found it to be more than adequate as a base for that ecosystem, specifically languages like C# and C++-CLI. Some changes were needed to LLVM in order to support precise garbage collection but they were fairly minimal. Debugging worked very well, though it wasn't as full featured as Visual Studio's .NET debugging environment it was abo…
See Julia ( http://julialang.org ) for an example of a dynamic language that uses LLVM rather successfully (IMO).
This article has a lot of interesting stuff, though it tends to be largely cheerleading LLVM's design decisions, rather than delving into the really interesting tradeoffs. For example, some compilers use multiple levels of optimizer IR, for example Open64/Pathscale. This allows them to perform more high-level language-specific optimizations. LLVM forces front-ends to lower their code directly down to its fairly low l…
This is not very surprising, the author of the article is Chris Lattner, one of the architects of LLVM and Clang. Maybe he should have made this clear upfront.
The original source for this LLVM article is a chapter in the Architecture of Open Source Applications (AOSA), and the LLVM chapter is available at: http://www.aosabook.org/en/llvm.html> ; AOSA is now a two-volume book " rel="nofollow">http://www.aosabook.org> , with chapters providing overviews of 49 open source projects.
Thanks for the links. BTW, the trailing ">" you are inserting is getting caught in HN's automatic linking and being inserted into the tag.
http://www.ietf.org/rfc/rfc1738.txt>
Earlier quoted context omitted.
Thanks for the links. BTW, the trailing ">" you are inserting is getting caught in HN's automatic linking and being inserted into the tag.
RFC1738 - Uniform Resource Locators (URL) - recommends use of angle brackets in its "Recommendations for URLs in Context" appendix; when URLs are embedded in text. http://www.ietf.org/rfc/rfc1738.txt> ;
Earlier quoted context omitted.
RFC1738 - Uniform Resource Locators (URL) - recommends use of angle brackets in its "Recommendations for URLs in Context" appendix; when URLs are embedded in text. http://www.ietf.org/rfc/rfc1738.txt> ;
Sure, but HN mangles the links. If this was email it might make more sense - or if HN's auto-parsing code were changed.
It's filled with pedants.
Some of us are even RFC-compliant.