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

46 comments

  1. Wishy Washy... by dmayle · · Score: 2, Interesting

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

  2. LLVM Progress by sabre · · Score: 5, Informative
    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.

    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 to see the rate of progress.

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

    -Chris

    1. Re:LLVM Progress by tilk · · Score: 1

      They didn't build a full C/C++ compiler, they modified GCC to emit LLVM assembly.

    2. Re:LLVM Progress by manyoso · · Score: 1

      Which, in and of itself, is no small feat!

    3. Re:LLVM Progress by Anonymous Coward · · Score: 1, Informative

      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.

    4. Re:LLVM Progress by sabre · · Score: 1

      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

  3. YAVM? by RAMMS+EIN · · Score: 5, Interesting

    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.
    1. Re:YAVM? by SewersOfRivendell · · Score: 1
      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 virtual machines.

      There is a Python implementation on each of these VMs (except LLVM), but it's incomplete (and possibly outdated) on some of them. So there is no basis for apples-to-apples comparisons quite yet.

  4. some assembly required by _|()|\| · · Score: 3, Interesting
    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.

    1. Re:some assembly required by truth_revealed · · Score: 3, Interesting

      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.

    2. Re:some assembly required by RAMMS+EIN · · Score: 2, Funny

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

      --
      Please correct me if I got my facts wrong.
    3. Re:some assembly required by RAMMS+EIN · · Score: 2, Interesting

      ``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 next step is to build a code generator. I was thinking about generating PPC and x86 assembly, and perhaps Java bytecode, but it looks like I should give LLVM a spin, too.

      --
      Please correct me if I got my facts wrong.
    4. Re:some assembly required by Anonymous Coward · · Score: 0

      If you have problems (you are not the only one) with LR generators, try using a LL one. ANTLR or JavaCC are good alternatives. Especially ANTLR's generated code (also C++, but I use Java) is quite easy to debug. IMHO, LR generators are out of fashion.

    5. Re:some assembly required by Anonymous Coward · · Score: 0

      Funny?

      Seriously. Lisp was slagged off as horribly bloated back in the day (remember when emacs was laughingly expanded as "eight megs and constantly swapping"? Wow. eight whole megs....). But lisp stuff is still roughly the same size, and compared to java or the like is a streamlined thing of beauty. Lisp's time is not yet come. But it is getting closer.

    6. Re:some assembly required by orthogonal · · Score: 1

      ``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 most aggressive example of C++ template meta-programming -- and his Loki template library even use recursive CAR-CDR like structures to implements lists and recursive algorithms to process those lists.

      So, in some ways, you have been given back your LISP. :)

    7. Re:some assembly required by _|()|\| · · Score: 1
      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.

    8. Re:some assembly required by truth_revealed · · Score: 1

      I agree that C++ template meta-programming is a resource pig at compile time but it produces very quick and tight code for runtime. I think it was the Spirit example Pascal or HTML grammar that took 500 Megs to 1 Gig to compile on GCC but in the end it produced a 250K .o object file. Ideally, you only need to compile that file just once ;-).

    9. Re:some assembly required by Anonymous Coward · · Score: 0

      While template meta-programming is very LISP like in some ways the syntax is just horrible.

    10. Re:some assembly required by kaffiene · · Score: 1

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

    11. Re:some assembly required by Anonymous Coward · · Score: 0

      typedef is your friend.

  5. "VM" in LLVM name does not do it justice by truth_revealed · · Score: 3, Interesting

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

    1. Re:"VM" in LLVM name does not do it justice by RAMMS+EIN · · Score: 1

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

      --
      Please correct me if I got my facts wrong.
    2. Re:"VM" in LLVM name does not do it justice by RAMMS+EIN · · Score: 1

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

      --
      Please correct me if I got my facts wrong.
    3. Re:"VM" in LLVM name does not do it justice by Anonymous Coward · · Score: 0

      GCC was produced by the Free Software movement, not the Open Source crowd.

  6. excitement by egott · · Score: 2, Interesting

    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.
    1. Re:excitement by Anonymous Coward · · Score: 0

      This post makes no sense at all.

  7. The most important question by ttfkam · · Score: 3, Interesting

    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.
    1. Re:The most important question by CaptnMArk · · Score: 2, Insightful

      This is true for Java. But only a small part of .net is actualy "standardized".

    2. Re:The most important question by RAMMS+EIN · · Score: 1

      ``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 on VMs that were designed with only another language in mind (e.g. the Java VM).

      To me, the VM _is_ the bytecode, syntax is the programming language, and standard libraries is what enables it to be used for Real World projects. That's why I asked about the properties of the VM and bytecode per se, not about existing code.

      --
      Please correct me if I got my facts wrong.
  8. Speaking as a GCC maintainer, I call bullshit by devphil · · Score: 4, Informative


    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.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    1. Re:Speaking as a GCC maintainer, I call bullshit by truth_revealed · · Score: 1

      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 how much better a compiler it would be if coding for it would be easier.

    2. Re:Speaking as a GCC maintainer, I call bullshit by devphil · · Score: 1


      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 accusing unrelated coders of deliberately and maliciously breaking it to make your life difficult is just, what, a technique of rhetoric? We're supposed to... look past it and ignore the FUD? Read your mind? Hope the other /. readers know you're full of it?

      Your points in the post to which I'm now responding are completely valid. Most, if not all, of the GCC maintainers would agree with them. Why you didn't just say so, instead of smearing us with lies, is something that I don't understand and that you've conveniently not mentioned. Don't bother now, I don't care, one more armchair judge in the killfile don't fash me none...

      --
      You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    3. Re:Speaking as a GCC maintainer, I call bullshit by True+Grit · · Score: 1
      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 true, why hasn't another fork occurred (or is this C++ issue the first time RMS has used his unlimited veto power)?
    4. Re:Speaking as a GCC maintainer, I call bullshit by Anonymous Coward · · Score: 0

      My god, I had never thought that someone could personify GCC to such a degree. Holy crap :)

      Do you have a blog I wonder??

    5. Re:Speaking as a GCC maintainer, I call bullshit by truth_revealed · · Score: 0, Troll

      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.

    6. Re:Speaking as a GCC maintainer, I call bullshit by devphil · · Score: 3, Informative


      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.

      --
      You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  9. RMS vs. Open Source by GCP · · Score: 3, Informative

    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.

    --
    "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
    1. Re:RMS vs. Open Source by devphil · · Score: 1


      Yep. Most of the maintainers would agree with you.

      Remember, in Free Software, you have the freedom to do anything you want -- except disagree with RMS.

      --
      You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    2. Re:RMS vs. Open Source by Anonymous Coward · · Score: 0

      RMS' quarrel is with proprietary software. Everything GNU licenses is available commercially. And it's the Open Source crowd that came on the heels of Free Software and then diverged, disregarding the ethical problems inherent in preventing people from modifying or learning from the software they need to use.

    3. Re:RMS vs. Open Source by Anonymous Coward · · Score: 0

      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.

      You're wrong.

      You see, there's nothing to stop a GPL'd program making direct use of the GCC code. If you want to write a GPL'd backend to the GCC frontends, you can just take the GCC frontends and put them in your program.

      The only time you'd want to use an intermediate output file would be if you wanted to avoid linking your program to the GCC sources - i.e. if you wanted to avoid having to GPL it.

      Okay, so it would also be impossible to write a backend that was licensed under the BSD license, say. That might conceivably be a problem for GPL haters. But it's hardly news that you have to GPL your program if you want to use GNU source code in it...

  10. Can it act as a sandbox? by Anonymous Coward · · Score: 0

    There were a few mentions of the "LLVM Verifier" but nothing about whether it's possible to use LLVM to run untrusted code while preventing it from having unlimited access to the underlying platform. Since both JVM and IL can, a new instruction set that can't would be a big step backwards.

  11. A compiler in C++ is not as easily bootstrapped by tepples · · Score: 1

    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.

    1. Re:A compiler in C++ is not as easily bootstrapped by dkf · · Score: 1
      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 out there). If GCC was rewritten in C++, the first step would be to make a bootstrap C++ compiler in C (preferably K&R-stype C too; there are *very* crufty systems out there!) so you could build the main compiler.

      (As a bootstrap compiler it would have the advantage of not needing to implement the entire language or do significant optimization. It just needs to build a working compiler...)

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    2. Re:A compiler in C++ is not as easily bootstrapped by devphil · · Score: 1


      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 (whatever the current version is at the time).

      Yes, #3 is a bit of a hassle, but it's a one-time hassle, and the hassle for a few people is outweighed by the benefits to the developers who have to work on the code every day.

      [*]The two big examples of the situation you mention are Solaris and HP/UX. For the Solaris users who don't buy the WorkShop compiler, there are umpteen binary packages of GCC out there. For the HP/UX compiler, the full host compiler is so troublesome that H-P themselves distribute GCC binaries.

      And if the idea of binary packages for C++ scare the hypothetical stranded user, then he can just get the C compiler and then do the double-bootstrap step above.

      --
      You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    3. Re:A compiler in C++ is not as easily bootstrapped by swagora · · Score: 1

      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) to C code on a supported platform by using the "C" backend
      • Move the C code to the new platform
      • Compile the LLVM "C" code to get a C++ compiler on the new platform
      • Move all of LLVM C++ code to the new platform and compile

      Just thought you should know what the plan is for bootstrapping LLVM.

  12. standard libraries by ttfkam · · Score: 1

    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 development of a language, the struggle between academia and tradesmen, or something else?

    --

    - I don't need to go outside, my CRT tan'll do me just fine.