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."

Comments

YAVM?

[RAMMS EIN]

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...

some assembly required

[_|()|\|]

This looks like a terrific tool for someone who has finished the front end of a compiler and wants to save some time on the back end. I'm still struggling with a project to build the front end, so I'm always on the lookout for tools to help me with parsing. I've dabbled with several, but I keep coming back to Bison. Recent releases (I'm using 1.875c, I think) include a Tomita-style generalized LR parser generator that is a god send for a newbie like me.

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.

Re:some assembly required

[truth_revealed]

If you are looking for a C++ only parser consider Spirit. It is a C++ lex/yacc equivalent where you do not need a preprocessor program of any kind - you write in 100% C++ only. But be warned - you need a gigabyte of memory and a lot of time to compile when you are dealing with large grammars as Spirit does all its magic with C++ templates and extensive operator overloading.

"VM" in LLVM name does not do it justice

[truth_revealed]

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.)

The most important question

[ttfkam]

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.