If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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.
So even if it worked, it sounds like it would be hugely impractical.

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...http://www.phoronix.com/vr.php?view=MTQ4NDY

@Michael:
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./

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

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