JIT Compiler Support Might Be Added To GCC 4.9
Phoronix: JIT Compiler Support Might Be Added To GCC 4.9
The recently announced just-in-time (JIT) compiler library using the GNU Compiler Collection might be added to the major GCC 4.9 release in 2014...
Very interesting, one question though, would one be able to compile an entire program to bytecode, and make it architecture independant (similar to Java)? Assuming of course, that the code itself was designed to run on multiple architectures.
Maybe then everyone would have to have all the libraries and developer libraries installed.
Originally Posted by j2723
So even if it worked, it sounds like it would be hugely impractical.
Yes, or one would also have to supply the bytecode-compiled libraries alongside the program (or statically linked into your bytecode program (and jitted at runtime as well)?).
Bytecode-compiled applications should work with native libraries.
Originally Posted by j2723
I wonder if this would be covered by the runtime library exception...
Originally Posted by phoronix
s/With LLVM has long supported JIT compilation, this is a first for GCC./While LLVM has long supported JIT compilation, this is a first for GCC./
Well, they are in different markets.
Originally Posted by timofonic
Parrot is targetted at dynamic language. Think Perl, Python and all the associated weirdness (their special type of closure, dynamically typed variables, etc.) It's good for stuff which don't really directly translate into machine code. (Well in the end, it's still executed by a CPU, but some of the quircks don't directly translate into machine code, but would have be handled by complex libraries).
GCC's bytecode is very close to LLVM IR. It targets a completely different category of uses cases.
Think PNaCl, think OpenCL.
The idea is to compile a statically typed language which can be translated into machine code. But don't translate it imediately. Instead store intermediate representation, and compile it at the last moment, so you can target the specific local architecture. It's good for stuff which do translate 1:1 with machine code (think C) but you don't want to translate it until you know exactly which machine's code. (Typical use case: algorithm that you ship with a software to process data. But you don't know which exact SIMD extension the CPU has. So either you re-compile it several time, once for each type of SIMD [they it was done until now]. Or, you compile it to bytecode and let the JIT compile exactly for the sub version of SSE/AVX/whatever).
Thanks for the great explanation.
Originally Posted by DrYak
That sounds like a huge win for packagers.
At a minimum they'd be able to get rid of the x32/x64 split and halve their repo size. Of course they'd still have to carry enough binaries to boot-strap the machine.
Tags for this Thread