4 ms·

Thanks for the rare fair comment. People are quick to forget the difference between concept and implementation. The Transmeta concept was clearly viable, but t

Thanks for the rare fair comment. People are quick to forget the difference between concept and implementation. The Transmeta concept was clearly viable, but the implementation needed more iterations to before we can fully judge the concept. Your comment about VLIW is true, but in this case that was a 2nd order effect. Far far worse was The effect of the JIT (CMS): a small kernel running over a long time (e.g., DVD playback) would work absolutely excellently, even on the Crusoe, whereas a large codebase with relatively little reuse (say, Word) would give very uneven performance. This problem was never solved [at Transmeta]. The irony is that today, x86 compability is irrelevant in most places.

PeCaN 9y ago
Yeah, code-morphing/hardware JIT is extra weird (and probably why Nvidia's Project Denver kinda tanked—turns out, that doesn't work too great for smartphone apps). One thing I've thought about is having a code-morphing CPU as a sort of accelerator that a single process could be offloaded to (of course, this would require an OS that can marshal processes). Think a database server, a JVM, NodeJS—long-running processes that would benefit from JIT. Might even be viable with upcoming cache-coherent interconnects like CCIX and GenZ. A more ambitious implementation could offload groups of functions.