Jonathan MERCIER <bioinfornatics@xxxxxxxxx> wrote: > LLVM itself could allow for much greater flexibility in programming > language choice. It can allow for anyone to take any language and output > it in bytecode, machine code, javavm code and so on. Sorry, but many interpreted languages (like Python, Perl, even emacs LISP) have their own bytecode (for good reasons, most of the time) and their own compilers to said bytecode. JVM is a _terrible_ architecture (somebody quipped it was carefully designed to be impossible to implement efficiently), other bytecodes are even more tailored for their respective languages. So this isn't _that_ great an idea. > If we can rip out > the multitude of compilers on different architectures and replace it > with one compiler base that does many different languages people might > start picking languages based on their merits rather than support (since > it just needs LLVM support to be supported). This idea was behind a dream of an universal intermediate language (UIL or some such). The problem is that designing such an UIL is extremely hard to do (and wasn't done because of that): You have to encode enough of the source code to be useful for the back end, and hide enough of the target to make the frontend truly target-independent; all the while not leaving too much hard work for the backend. Consider the variety of source languages you want to use: Perl (dynamic, heavily text based), C (static, "high level assembly language"), C++ (machine-near object oriented), Java (with guarantees that nothing can go too far off), functional languages like Haskell or Scheme, stuff like Erlang, ... > If we could swap out old C compilers for a more generic LLVM compiler > for core components like the kernel, Won't happen until clang generates much better code than GCC; in the meanwhile it'll have to grok all GCC extensions. > userspace libs Ditto (mostly) > and so on. In the > future people might just make the decision to move to D since the > architecture is all there and all their old code works but they get all > the new features. Would need compatilility shims to extant C libraries. Plus people won't just rewrite years of work if it isn't for _massive_ advantages (twice as fast or one tenth of the bugs for little work). > Think of Linux distros being built entirely on LLVM. > There are also the other advantages such as dumping in JIT compilers and > automatic threading in LLVM to take advantage of the many processors > systems are starting to get. Automatic paralelization is still a just a glint in researcher's eyes, some 50 years later... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
