Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Announcements

Low Level Virtual Machine 1.3 Released 46

Posted by michael from the just-like-bare-iron dept.
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."
This discussion has been archived. No new comments can be posted.

Low Level Virtual Machine 1.3 Released More

Low Level Virtual Machine 1.3 Released

Comments Filter:

  • Wishy Washy... (Score:3, Interesting)

    by dmayle ( 200765 ) on Saturday August 14, 2004 @02:47AM (#9966111) Homepage Journal

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

    • LLVM Progress (Score:5, Informative)

      by sabre ( 79070 ) on Saturday August 14, 2004 @03:07AM (#9966156) Homepage
      LLVM is an active and vital project with a growing user base and active developer community. If you'd like to chat with some of the devs, stop in to the irc channel [irc].

      LLVM is a very young project (only 3 years old) but has already made dramatic progress in it's time. Check out the status updates on the left hand side of the main site [llvm.org] to see the rate of progress.

      Building a full C/C++ compiler is no small feat!

      -Chris

      • They didn't build a full C/C++ compiler, they modified GCC to emit LLVM assembly.
        • Which, in and of itself, is no small feat!

          • Re:LLVM Progress (Score:1, Informative)

            by Anonymous Coward
            Uh. One of the things gcc is designed for is easy implementation on new architectures (it foregoes many arch-specific optimsations because of this). That's why the first compiler on any new CPU arch is often gcc. The only thing in this case is that the arch is virtual. So, it _is_ not "easy" to port gcc to LLVM, but it is orders of magnitude easier than almost any other C compiler out there.
            • Actually, this is incorrect. The LLVM-gcc front-end completely replaces all of the optimizations and code generation phases of GCC (if you're familiar with GCC, it eliminates all of the RTL related stuff).

              llvmgcc is a very substantial change to GCC, and it doesn't use any of the retargetting features that GCC has. Also, LLVM provides its own optimizers and code generators, which produce substantially better code than GCC in many cases (e.g. 30% speedup for C++ codes is not uncommon).

              -Chris

  • YAVM? (Score:5, Interesting)

    by RAMMS+EIN ( 578166 ) on Saturday August 14, 2004 @05:32AM (#9966398) Homepage Journal
    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...

    • The most important question (Score:4, Interesting)

      by ttfkam ( 37064 ) on Saturday August 14, 2004 @12:08PM (#9967852) Homepage Journal
      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.
      • This is true for Java. But only a small part of .net is actualy "standardized".
      • ``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.''

        See, I differ with you there. Standard libraries can be implemented on nearly anything. The choice of VM, for me, depends on the flexibility and power of the bytecode, and how well it can be converted (run time or ahead of time) to native machine code. The reason I mentioned Common LISP is that it's can be notoriously hard to implement o
        • All I'm saying is that if Java didn't have all of the items in java.util or built in threading or a standard database API, no one would've used it.

          This doesn't help Common LISP as you correctly point out, but without a standard library, any language or VM is likely to be ignored.

          That said, I'm curious about one of your statements. If standard libraries can be implemented on nearly anything, why haven't they been implemented? Do you think this is the result of a single company controlling the initial dev
    • They don't really compare as easily as you'd think.

      LLVM is target at traditionally static languages such as C and C++. Java and .NET VM are targeted at Java-like languages. Parrot is focused on highly dynamic languages that traditionally have been interpreted, such as Perl, Python, Ruby. SmallTalk would in theory be more comfortable on Parrot than on .NET.

      This is not to say you can't implement C++ on Parrot, or Lisp on .NET CLR, only that it isn't the intended focus of the authors of the respective virt

  • some assembly required (Score:4, Interesting)

    by _|()|\| ( 159991 ) on Saturday August 14, 2004 @07:31AM (#9966625)
    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.

    • If you are looking for a C++ only parser consider Spirit [sourceforge.net]. It is a C++ lex/yacc equivalent where you do not need a preprocessor program of any kind - you write in 100% C++ only [sourceforge.net]. 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.
      • ``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.''

        Holy Cow!!! Give me back my LISP...
        • ``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.''

          Holy Cow!!! Give me back my LISP...

          Template meta-programming actually is rather LISP like, not least because you have only values and not variables to work with. Rather than assign a value to a variable, all "meta-functions" must produce a new compile-time value.

          Alexandrescu's Modern C++ Design -- the m
    • ``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.''

      What's wrong with Bison that you keep looking for alternatives? I think you should just get over that stage and start coding the rest.

      For the record, I just wrote a parser and interpreter for a LISP-like language with Python-like syntax entirely in Python. It works (except that I didn't get lexical scoping right), and my
      • What's wrong with Bison that you keep looking for alternatives?

        Before I discovered the new GLR parser, I couldn't manage to write a LALR(1) grammar for the source language. The target language is Python, so I experimented with PLY, Spark, and others.

    • ANTLR is not bad: http://www.antlr.org/

  • "VM" in LLVM name does not do it justice (Score:4, Interesting)

    by truth_revealed ( 593493 ) on Saturday August 14, 2004 @09:13AM (#9966950)
    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.)
    • ``GCC recently voted down using C++ in their core code.''

      Which could be a very good thing. Last I checked, the code g++ generated was a lot less efficient than what gcc produced, even with plain C code. Perhaps optimization would solve that, but I've heard similar complaints from others, also about other C++ compilers. I believe that, in theory, C++ programs can be more efficient that C programs, but with current compilers, this seems not to be the case.
    • ``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.''

      Which, arguably, constitutes an ethical violation of the open source definition. It makes me wonder why there doesn't seem to be a fork of gcc that does not engage in this kind of madness. It might well grow more popular than the current project.

    • Speaking as a GCC maintainer, I call bullshit (Score:5, Informative)

      by devphil ( 51341 ) on Saturday August 14, 2004 @01:55PM (#9968783) Homepage


      The very best trolls always start with a grain of truth. (LLVM is much easier to understand than GCC. The GCC infrastructure is very baroque, dating from a time when assuming the presence of an ANSI C bootstrap compiler was too much. One of the major LLVM guys has presented his toolchain work at the annual GCC Summit, and maintains close communication with the rest of the GCC team -- and we wish him well. All very true; no GCC hacker would say any less.)

      The trolls then move on into wild exaggerations and complete lies. Such as:

      and try their damnedest to obscure and change the programming API from release to release.

      Pure malicious bullshit. RMS doesn't want proprietary backends to be able to read the GCC IR, and so we don't ever write it out in a machine-readable format. But we've never gone out of our way to obfuscate the internal API.

      GCC recently voted down using C++ in their core code.

      Again, a complete lie. We asked RMS whether we could make use of C++ in parts of the compiler. While a skilled and brilliant C and LISP hacker, RMS is a reactionary fuckhead when it comes to anything other than C or LISP. In his opinion, all GNU programs should be written in C, and only C, ever.

      There was no vote.

      • For a person who disagrees with what I wrote, you understand where I'm coming from. Yes, technically there was no vote on C++ - you're right. In the end the result is the same - GCC ain't gonna use C++ any time soon. Not having a vote is much worse than voting it down, in my opinion. The GCC project is very bureaucratic. On the other point you mentioned, too bad there is not a complete toy language for GCC for people to cut their teeth on. The GCC learning curve is pretty steep. I just can't help but think

        • What, you try to make common cause with me after outright attacking my friends and colleagues? Without an apology? You, "truth_revealed", are a liar and an asshole.

          technically there was no vote on C++ - you're right. In the end the result is the same

          So of course, lying about it, as if there had been a vote and the democratic process had somehow gone awry, is completely harmless. "Ends justify the means," or some other pisshead reasoning.

          Pointing to an abandoned and unmaintained toy language and

          • I contend that RMS not allowing a vote on C++ usage (or people not voting for fear of annoying RMS) is just the same as C++ being voted down.
            GCC is a great compiler designed by brilliant people. This is not in dispute. Mere mortals like me just wish its learning curve was not quite as steep.

      • RMS vs. Open Source (Score:4, Informative)

        by GCP ( 122438 ) on Sunday August 15, 2004 @01:21AM (#9972546)
        RMS doesn't want proprietary backends to be able to read the GCC IR, and so we don't ever write it out in a machine-readable format.

        Then open source backends won't be able to read it either, but that's apparently okay with RMS, given his priorities. Since only REALLY good commercial software would have a chance against a no-cost incumbent, he is willing to keep great open source alternatives from becoming available in order to keep great commercial alternatives from becoming available.

        This is the guy who proclaims that ALL commercial software developers are "unethical".

        Open Source to me is about openness: the source is yours to use as you wish, the code can be scripted externally via a command-line interface, it can be incorporated as a library into your own code with minimal effort with a nice API intentionally designed for that purpose, it has a modular architecture that encourages others to compete at the replacement module level without having to rebuild the whole app, etc.--all the ways code can be opened: the least restrictions and the greatest usability.

        This is not RMS's agenda. RMS has made his priorities clear. He has never claimed to support the "open source movement", only to be somewhat allied with it to the extent it supports his own anti-commercial software movement.

        We asked RMS whether we could make use of C++ in parts of the compiler. While a skilled and brilliant C and LISP hacker, RMS is a reactionary fuckhead when it comes to anything other than C or LISP.

        Having heard him speak on many occasions over the years, it's my impression that this characterization is correct and "anything other" applies to more than just programming languages, though not to everything.

        I think RMS is right on in many (but not all) of his compaints about IP laws. He's a very bright and skilled guy with a lot of great ideas, but his old-fashioned leftist political philosophies are more "anti" than they are "pro" and handicap the usefulness of his products in some unfortunate ways, and that appears to include GCC.

        To the extent that LLVM and other technologies compete with GCC, I'm all for it.

      • There was no vote.

        Sincere question: Have I had a complete misunderstanding about GCC ever since EGCS? My understanding was that EGCS started as a fork of GCC because of differences with the GNU people, but eventually they agreed/relented and allowed EGCS to merge with and/or replace the old GCC, and in the process opening up GCC development to new people (the ones responsible for EGCS). Are you saying that despite that, RMS still has dictatorial power over GCC and its "steering committee"? If this is

        • Re:Speaking as a GCC maintainer, I call bullshit (Score:4, Informative)

          by devphil ( 51341 ) on Sunday August 15, 2004 @01:16PM (#9974914) Homepage


          You're not completely right, and not completely wrong. The politics are exceedingly complicated, and I regret it every time I learn more about them.

          RMS doesn't have dictatorial power over the SC, nor a formal veto vote.

          He does hold the copyright to GCC. (Well, the FSF holds the copyright, but he is the FSF.) That's a lot more important that many people realize.

          Choice of implementation language is, strictly speaking, a purely technical issue. But it has so many consequences that it gets special attention.

          The SC specifically avoids getting involved in technical issues whenever possible. Even when the SC is asked to decide something, they never go to RMS when they can help it, because he's so unaware of modern real-world technical issues and the bigger picture. It's far, far better to continue postponing a question than to ask it, when RMS is involved, because he will make a snap decision based on his own bizarre technical ideas, and then never change his mind in time for the new decision to be worth anything.

          He can be convinced. Eventually. It took the SC over a year to explain and demonstrate that Java bytecode could not easily be used to subvert the GPL, therefore permitting GCJ to be checked in to the official repository was okay. I'm sure that someday we'll be using C++ in core code. Just not anytime soon.

          As for forking again... well, yeah, I personally happen to be a proponent of that path. But I'm keenly aware of the damange that would to do GCC's reputation -- beyond the short-sighted typical /. viewpoint of "always disobey every authority" -- and I'm still probably underestimating the problems.

      • We asked RMS whether we could make use of C++ in parts of the compiler. While a skilled and brilliant C and LISP hacker, RMS is a reactionary fuckhead when it comes to anything other than C or LISP.

        One of the requirements shaping the implementation of GCC is that it be bootstrappable on many systems, even on some UNIX(tm) systems shipped by their vendors with a half-broken C compiler (enough to recompile the kernel but not much more) and no C++ compiler.

        • One of the requirements shaping the implementation of GCC is that it be bootstrappable on many systems, even on some UNIX(tm) systems shipped by their vendors with a half-broken C compiler (enough to recompile the kernel but not much more) and no C++ compiler.

          Speaking as a maintainer of software that gets ported to some really odd environments, GCC's general policy in this area is a godsend (it lets the rest of the software toolchain stop worrying quite so much about every kind of bizarre compiler bug o

          • Bootstrapping is an issue for LLVM, but not as large an issue as some are trying to make out. One of the backend machines supported by LLVM is a "C" backend. That is, we can translate our IR to C code. This has been working for years now.

            While GCC provides a path to new machines for LLVM today, the long range plan is to have an LLVM based C++ compiler that needs nothing from GCC. When that happens, the bootstrapping plan will be:

            • Compile a subset of LLVM (just enough to correctly compile/run C++ programs

        • Oh believe me, this point is well understood by the maintainers. Lots of traffic on this subject. :-)

          The general consensus is that:

          1. Very few people need to bootstrap from a bare metal system, or an intentionally crippled compiler.[*]
          2. The people in the first situation are already familiar with chicken-and-egg scenarios, and the well-known steps to solve them.
          3. Those in the second situation can start with GCC version (whenever we make the switch) - 1, which was written in C, and then use that to get to (w

  • excitement (Score:2, Interesting)

    by egott ( 81357 )
    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

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close