3 ms·

It sounds very much like what current CPUs do, with x86 being mapped into execution units dynamically via microcode, except (I assume ? article was very low on

by adql 3y ago

It sounds very much like what current CPUs do, with x86 being mapped into execution units dynamically via microcode, except (I assume ? article was very low on detail) in case of Crusoe it just did it for big VLIV instruction blobs.

FullyFunctional 3y ago
No there are major differences. A non-exhaustive list: * Crusoe/Efficeon/... used a software JIT (called CMS) * Ran on a very custom architecture (P95/P2000) designed for JITted code with speculation (software controllable checkpoints, "assert" instructions, speculative cache, small lookup tables for translating x86 addresses to P95 etc). * It had no dynamic scheduling, reorder buffer, renaming, etc. The thesis was to eliminate the power/area hungry parts of microprocessors by having the "compiler" (= JIT) do it up front. Some things worked well (very power efficient, small die). Others less so: huge cold code penalty, limited ability to deal with large cache misses (like IA-64). Transmeta had a huge impact on the industry; Intel has officially credited Transmeta and Transmeta's LongRun with getting Intel focused on power. Both NVIDIA and "another company" have explored the CMS idea. There is so much to the Transmeta story and the failure was more of a business issue than a technical one. This was a completely new approach and Transmeta needed more iterations to refine the idea. ADD: A VLIW "instruction" (called a "molecule" in TM terminology) is compiled, fetched, issued, and (mostly) executed as a (parallel) unit. That is very very different from what modern superscalar microprocessors do. They issue instructions from many issue queues. The instructions that execute in the same cycle usually do so mostly as a consequence of data-flow and the current state of the pipeline. Large x86 instruction translated to microcode typically leads to many µops that do not execute in parallel, but are intermixed with other µops.
PAPPPmAc 3y ago
Yup, since the NexGen Nx586->AMD K6 and Intel P6 (Pentium Pro) generations, which were contemporaries of Transmeta's founding in ~1995, modern x86 parts are pretty much a dynamic JIT in silicon in front of whatever fancy internal architecture the vendor designed that generation. Honestly, if you look at recent parts, the internal designs are _super_ wide multi-issue like a VLIW, it's just a difference of sophistication vs. coupling in your JITy thing. Let's use Intel Sunny Cove as an example because it's recent and there is a good diagram on Wikpedia: https://en.wikipedia.org/wiki/Sunny_Cove_(microarchitecture) https://en.wikipedia.org/wiki/Sunny_Cove_(microarchitecture) Because they're wide multiple issue (SC: 8 execution units wide), the internal execution is fairly VLIW-like. Unlike an exposed VLIW, it's plausible possible to actually fill all those pipes because they're doing dynamic out-of-order issue on a window of (sort of hard to count, SC:something like 50) instructions coupled to all the register renaming and memory access scheduling to keep instructions out of each others way. Transmeta's proposition was not really super wild, Multiflow (and very briefly Apollo) were building VLIWs in the 80s, so that wasn't crazy. Their core trick was splitting the difference between the dynamic decomposition driven out of order/multi issue/superscalar designs that used relatively dumb, shallow heuristics but were very dynamic and close to the hardware (like above), and the compiler-driven RISC/VLIW designs that tried to do fancier scheduling and optimization on larger units but were much more static and more removed from the execution process. The fast dumb heuristics close to the hardware won in a _big_ way over all competitors.

by adql 3y ago

FullyFunctional 3y ago

No there are major differences. A non-exhaustive list: * Crusoe/Efficeon/... used a software JIT (called CMS) * Ran on a very custom architecture (P95/P2000) designed for JITted code with speculation (software controllable checkpoints, "assert" instructions, speculative cache, small lookup tables for translating x86 addresses to P95 etc). * It had no dynamic scheduling, reorder buffer, renaming, etc. The thesis was to eliminate the power/area hungry parts of microprocessors by having the "compiler" (= JIT) do it up front. Some things worked well (very power efficient, small die). Others less so: huge cold code penalty, limited ability to deal with large cache misses (like IA-64). Transmeta had a huge impact on the industry; Intel has officially credited Transmeta and Transmeta's LongRun with getting Intel focused on power. Both NVIDIA and "another company" have explored the CMS idea. There is so much to the Transmeta story and the failure was more of a business issue than a technical one. This was a completely new approach and Transmeta needed more iterations to refine the idea. ADD: A VLIW "instruction" (called a "molecule" in TM terminology) is compiled, fetched, issued, and (mostly) executed as a (parallel) unit. That is very very different from what modern superscalar microprocessors do. They issue instructions from many issue queues. The instructions that execute in the same cycle usually do so mostly as a consequence of data-flow and the current state of the pipeline. Large x86 instruction translated to microcode typically leads to many µops that do not execute in parallel, but are intermixed with other µops.

PAPPPmAc 3y ago

Yup, since the NexGen Nx586->AMD K6 and Intel P6 (Pentium Pro) generations, which were contemporaries of Transmeta's founding in ~1995, modern x86 parts are pretty much a dynamic JIT in silicon in front of whatever fancy internal architecture the vendor designed that generation. Honestly, if you look at recent parts, the internal designs are _super_ wide multi-issue like a VLIW, it's just a difference of sophistication vs. coupling in your JITy thing. Let's use Intel Sunny Cove as an example because it's recent and there is a good diagram on Wikpedia: https://en.wikipedia.org/wiki/Sunny_Cove_(microarchitecture) https://en.wikipedia.org/wiki/Sunny_Cove_(microarchitecture) Because they're wide multiple issue (SC: 8 execution units wide), the internal execution is fairly VLIW-like. Unlike an exposed VLIW, it's plausible possible to actually fill all those pipes because they're doing dynamic out-of-order issue on a window of (sort of hard to count, SC:something like 50) instructions coupled to all the register renaming and memory access scheduling to keep instructions out of each others way. Transmeta's proposition was not really super wild, Multiflow (and very briefly Apollo) were building VLIWs in the 80s, so that wasn't crazy. Their core trick was splitting the difference between the dynamic decomposition driven out of order/multi issue/superscalar designs that used relatively dumb, shallow heuristics but were very dynamic and close to the hardware (like above), and the compiler-driven RISC/VLIW designs that tried to do fancier scheduling and optimization on larger units but were much more static and more removed from the execution process. The fast dumb heuristics close to the hardware won in a _big_ way over all competitors.