3 ms·
I think that Transmeta (and the others working on the same stuff at the same time) had fixed instruction sets, along with hardware and software to recompile x86
by Taniwha 5y ago
I think that Transmeta (and the others working on the same stuff at the same time) had fixed instruction sets, along with hardware and software to recompile x86 code into that instruction set.
The difference here I think is not that the chips don't have an instruction set, they do, but they don't have an ARCHITECTURAL instruction set, the next version of the chip will have a different instruction set and a matching LLVM back end - they expect you to recompile your code for every new CPU.
What I don't see in the literature is any mention of MMUs and system level stuff - I'm sure it's there
- hermitdev 5y agoDidn't we already have this with Java? Write once, run anywhere and the hardware would magically adapt the incoming code to run on the new hardware? Except now, it's LLVM byte-code instead of Java (and x86 asm)? I'm not trying to be cynical here, but I can see how this would sound like that. I guess I'm just confused about what this actually is and how it is new/different than all of the things that have been tried before.
- Taniwha 5y agoI think the difference (my impression from little data :-) is that this is (mostly) not JIT but instead more in depth static compilation of basic blocks into code. The big change here is the abandonment of the concept of an architectural ISA - it depends on software people (all of them/us) giving up assembler - I think it's probably the right way to approach high ILP VLIW-like cpus - it means you don't get hung up on your old CPU designs as you move forwards