3 ms·
The basic idea was sound, and in fact is largely what modern devices have settled on: a core execution engine based around a uOp cache (that's the modern term;
by ajross 2y ago
The basic idea was sound, and in fact is largely what modern devices have settled on: a core execution engine based around a uOp cache (that's the modern term; no idea what TM called it) and not raw instructions, which is fed by a decode layer that cooks the instruction down into dispatch-friendly (essentially VLIW-ish) variants that have already resolved most of the complicated pipeline dependencies.
But: (1) Getting that to work with the transistor budget available to a 250nm chip is hard, and the value is comparatively low: there just weren't that many execution units to dispatch to! In some sense they were ahead of their time; Sandy Bridge ended up making it work almost a decade later.
And more importantly: (2) Intel at the time was at the peak of its process ascendency. Transmeta might have made a competetive CPU at the circuit level, but not when their fabs were a full process node behind. NVIDIA and ATI, at the time, were having a ton of success in the industry because they weren't trying to compete with Intel.
- buran77 2y agoTransmeta also has 130nm CPUs [0] but they were all meant to be low power. The 130nm TM5800/5900 were ~9W at their highest 1GHz rating including the integrated northbridge. Clock it down to 800MHz and it was a measly 5-6W. That wasn't much power to work with, especially for a CPU that was doing the extra work for the code morphing abstraction layer. The similarly clocked Pentium IIIs going around the same period were ~30W. I had a Compaq TC1000 for some time and I while I loved it for it's exotic nature and interesting approach, it was slow as molasses. [0] https://datasheets.chipdb.org/Transmeta/pdfs/brochures/crusoe_for_embedded_applications.pdf https://datasheets.chipdb.org/Transmeta/pdfs/brochures/cruso...