As someone who worked on operating systems back at Multiflow (late 80's, the first VLIW start-up as a spin-off from Yale research), it struck me recently that something like an LLVM representation of binary code might solve the "compiler problem" (needing to know the exact specifics of the chip's latencies). I.e., you'd run and load LLVM binaries, and have a runtime final optimization pass that took into account the specific latencies of each opcode for a particular implementation. (The LLVM architecture is actually already set up to do optimizations at runtime on LLVM "binaries".)
But perhaps that "final optimization pass" would be nearly as hard as the whole compilation problem in the first place; dunno. I wasn't on the compiler team, so this is perhaps a naive viewpoint.
The LLVM architecture is actually already set up to do optimizations at runtime on LLVM "binaries".
Pragmatically, exactly how fast is that run-time optimization? Could you realistically JIT it, or should the more-optimal, chip-specific asm be cached between loads? Or is this so slow you'd only ever want to do it once?
Right, forgot to say that: you'd cache the results (like Rosetta translation on the PowerPC or the DEC VAX-to-Alpha binary recompilation) so you'd only take the translation hit once.
Transmeta was doing dynamic binary translation from x86 to VLIW. I think the grandparent comment is saying that you could distribute programs in an IR and then compile them before running.
Comments
As someone who worked on operating systems back at Multiflow (late 80's, the first VLIW start-up as a spin-off from Yale research), it struck me recently that something like an LLVM representation of binary code might solve the "compiler problem" (needing to know the exact specifics of the chip's latencies). I.e., you'd run and load LLVM binaries, and have a runtime final optimization pass that took into account the specific latencies of each opcode for a particular implementation. (The LLVM architecture is actually already set up to do optimizations at runtime on LLVM "binaries".)
But perhaps that "final optimization pass" would be nearly as hard as the whole compilation problem in the first place; dunno. I wasn't on the compiler team, so this is perhaps a naive viewpoint.
Pragmatically, exactly how fast is that run-time optimization? Could you realistically JIT it, or should the more-optimal, chip-specific asm be cached between loads? Or is this so slow you'd only ever want to do it once?
Right, forgot to say that: you'd cache the results (like Rosetta translation on the PowerPC or the DEC VAX-to-Alpha binary recompilation) so you'd only take the translation hit once.
Transmeta was a little like that, except it was x86 to VLIW.
Transmeta was doing dynamic binary translation from x86 to VLIW. I think the grandparent comment is saying that you could distribute programs in an IR and then compile them before running.