Slashdot Mirror
Low Level Virtual Machine 1.3 Released
RSpencer writes "The Low Level Virtual Machine project has released version 1.3. There are full release notes available. LLVM is a source-language agnostic toolkit for building compilers, optimizers, and jit or interpreted virtual machines. LLVM provides extensive optimization support, three mid-level IR formats (bytecode, assembly, and C++), three backend targets (x86,Sparc,PPC), full documentation, and a very simple and unique design. This new toolkit approach to compiler related tools is quickly attracting new developers who are making significant contributions to the work. Visit the home page where you can learn all the details. LLVM is funded by the National Science Foundation, MARCO/DARPA, and supported by UIUC's Computer Science department and other developers."
In some ways, I think this is neat. Dynamic recompilation is starting to become necessary in a lot of software (SQL, for databases, the code for emulation, hell just providing a scripting language for customizing your software would make use of this.)
On the other hand, I've been kind of jaded by lots of little projects that didn't end up doing too much. Who knows? This could become another Sqlite (An invaluable tool in my toolkit that allows anyone to incorporate a very full-featured database into their code, with all of the code in the public domain. [As soon as I have something to contribute back, I will, but it's hard to do, since they do such great work, and quickly, too.])
I'm gonna give this a try, and keep my fingers crossed...
So...now we have various implementations of the Java VM, the .NET VM, Parrot, and LLVM, plus various emulators of real machines, and let's not forget the real machines themselves.
What I would like to know is how they all compare. How fast does a typical program run? How portable is the implementation; how easy can the bytecode be transformed to native code for various architectures? How easy is it to target this machine? How well does the machine cope with various programming languages (esp. Common LISP)? How stable (backward compatible) is the bytecode? What are the licensing terms? Does it communicate with the host system, and how well? Etc...
Please correct me if I got my facts wrong.
If I ever do build a satisfactory parser with Bison, I wonder how it would interface with LLVM. I tried converting a toy Bison parser to C++ and it seemed like there were some rough edges.
The casual Slashdot reader may roll his/her eyes when they see yet another Virtual Machine - but this project is much more than that. It's a complete compiler infrastructure project that will one day surpass GCC. Why? Because it's around ten times easier to understand and written in a modern language (C++) rather than C. An expert C++ programmer could start contributing code to LLVM in under a month; whereas an equivalent learning curve for GCC is at least a year. Writing new compiler passes or complete language front ends for LLVM is very straight-forward, for example. The LLVM AST has the advantage of having strong typechecking and not arcane tree macros as in GCC. LLVM is not burdened with the legal or philosophical wranglings of GCC where they do NOT WANT their compiler to be the backend of a commercial compiler and try their damnedest to obscure and change the programming API from release to release. The GCC "Toy" example language has not worked in many releases for this very reason.
GCC recently voted down using C++ in their core code. Perhaps LLVM at the very least will drag GCC into the modern age due to competition.
The VM part of LLVM is just icing on the cake.
(And yes, I am aware that LLVM uses GCC 3.4's C and C++ front-end code. That's a good thing for the short term. Perhaps longer term they will develop their own front-ends.)
Tools that simplify witting new languages excite me. I see many significant programming tasks as language interpretation or translation (compilation). The "language" doesn't have to be in the form of a concrete text file: interpretation could mean interpreting UI events; compilation could mean converting one data structure into another. From this perspective, meta programming (language authoring) is very important. Obviously not all parsing tasks are well served by lex and yacc, and similarly I wouldn't expect LLVM (or MLRISC, or whatever...) to be a perfect fit for all compilation tasks. But where they are a good fit I expect to be able to write software that is simpler, more robust, and more fully featured. That makes me happy.
There are 10 kinds of people: Those that understand ternary; those that don't; and those that don't care.
How complete is the API? The power of the Java and .NET VMs (I don't know Parrot well enough to comment) is their standard libraries -- perhaps to a larger extent than the bytecodes themselves.
Array bounds checking is not new. Dynamically loading code isn't new. What was new was the creation of a standardized toolkit and API that handled threading and network I/O and GUI and database access and XML parsing and... You get the picture.
Another portable VM holds little value for me if in the end I just end up back to the "good ol' days" of C where you were given a hammer and told to build a house. POSIX isn't enough.
- I don't need to go outside, my CRT tan'll do me just fine.