Bellard's TCC had a similar feature - it could be used to JIT scripts written in C, and libtcc was its library for dynamic code generation. Being much simpler it does nowhere near as much optimisation as GCC, but that also means it can compile much faster:
> a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4.
Hah! In 2004 (last news) maybe, and I wonder which featureset.
In fact, it's been a long time since I've compiled the kernel myself [1]. I wonder how long a minimal kernel takes to build nowadays. Of course, I guess "minimal" is even more ambiguous today than it was back then...
[1] Back in the day, "recompile your kernel" was the Linux joke answer to problems the way "try turning it off and on again" was for Windows...
On an i3 machine with plenty of RAM and an SSD, and GCC 4.9, a recent kernel builds in about 3.5 minutes. That's using the "defconfig" target, which is pretty bare-bones (only ext4, very few device drivers or fancy new features).
As another data point, Debian's kernel configuration on the same hardware takes 26 minutes to build.
I think 3.5 minutes down to less than 15 seconds for a recent kernel is probably possible. On the other hand, tcc generates code which runs 3.5x slower, so you'd have to be doing a lot of compiling and not much running for it to save any time. JIT'ing the kernel is a fun exercise, nonetheless.
From the perspective of using a JIT within python that the blog post raises you can see two different approaches of this being done in Python with the LLVM:
1) The pyston project from Dropbox is an attempt to build a python runtime sitting on top of the LLVM JIT
> Because with compiled languages that are not running on an VM like JVM it is impossible to use JIT compiling, because I don't have the source files.
Nonsense, you can jit compile either through the JVM (gen bytecode -> bytecode is jit'd) or through normal ways (llvm, poking memory and protecting it appropriately, etc.)
It is not completely true. See for instance what PNaCl is doing: you can compile C++ (or any similar compiled language) to (LLVM) byte code, and then JIT it at runtime.
Well, the blob is only added to the compiler portion of your code. Ex. In this article, only the Python script is under the GPL because of libgccjit. The .bf scripts shouldn't/don't have a requirement to be under the GPL.
Imagine you had a large application, and wanted to add this library to it. To comply with the GPL, your application would have to be under a GPL compatible license. Such applications are a smaller subset of all applications hence the question.
The LGPL does allow for the library portion to be GPL while the rest of the app doesn't have to be, but that isn't the license used in this case. Typically the LGPL favours more widespread adoption, while the GPL favours freedom at the cost of some adoption.
LLVM also has a JIT and a far more permissive license, making it more attractive to those not using a GPL compatible license.
You've always been able to use gcc to compile non-gpl code into an executable, and distribute it.
You've always been able to distribute a distro that includes gcc and also includes gpl-incompatible programs (like flash player, or apache-licensed programs).
What has to be GPL is the application that you combine the gcc code with, either when you link in the new libgccjit, or in your python code that imports the python module that links to libgccjit, or if you modify/extend the code for gcc itself (or other GPL codebases).
Can a GPL-licensed interpreter run non-GPL scripts? It seems like one should be able to build a GPL JIT+interpreter as a single application, then run whatever scripts they want on top of it.
The GPL applies to "derivative works", which is a legal term without a precise technical definition.
If you decide to write an interpreter for an existing language, and run existing programs on it, then those existing programs "probably" do not have to be under the GPL, for definitions of "probably" that Legal will not be happy about.
If you write an interpreter for a made-up language and then write programs in that language as part of a thinly-veiled scheme to do an end-run around the GPL, then that "probably" violates the GPL.
There is currently no bright-line rule separating those cases; this is something IP lawyers argue about themselves and reach wildly different conclusions.
http://bellard.org/tcc/tccboot.html
TCCBOOT is only 138 KB big (uncompressed code) and it can compile and run a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4.
It'd be interesting to see someone try a similar experiment with libgccjit.