5 ms·

I dont think Transmeta ended up being that influential. Sparc/Mips as the birth of RISC should be there.

angersock 13y ago
I was under the impression that they were munched by Intel and basically became the foundation for the microcode that those chips use now. Am I wrong?
- masklinn 13y ago
  > I was under the impression that they were munched by Intel Nope, you must be thinking about something else. Transmeta started moving into IP in 2005, sued intel for patent infringement in 2006 (settled for a cool 250mil, Intel got a perpetual, non-exclusive license out of it), licensed tech to Nvidia in 2008 and died in 2009 (was acquired by Novafora in January, Novafora collapsed in July but not before Intellectual Vultures made off with the patent stash in Feb) Now part of Intel's activity at the time (the PIII and Pentium M side which ended up with Core) may well have been inspired by Transmeta (as many allege), but at the same time Transmeta's activity best matches Intel's pursuit of the NetBurst (P4) shit-cake, which ran opposite to pretty much anything Transmeta looked for (unless Transmeta had patents on lofty promises they couldn't come close to deliver on, then year the P4 fits).
  - angersock 13y ago
    Ah, fantastic. Thanks for the info! Fun fact: TX/RX Labs (Houston Hackerspace) has a rack of old Transmeta blade servers that a former member donated.
  - Symmetry 13y ago
    There's speculation that NVidia's Project Denver is an Efficeon reworked to target ARM code rather than x86. So there might be a live Transmeta descendant out in the real world again in a few months. http://anandtech.com/show/7622/nvidia-tegra-k1/2 http://anandtech.com/show/7622/nvidia-tegra-k1/2 http://en.wikipedia.org/wiki/Project_Denver http://en.wikipedia.org/wiki/Project_Denver
- InclinedPlane 13y ago
  Not at all. The Transmeta is a really fascinating CPU architecture based around "code morphing", modern CPUs use something at a bit of a lower level: micro-op translation.
  - seanmcdirmid 13y ago
    Intel was doing micro-op translation way before 2005...it was something they introduced with the Pentium Pro. Their patent problems with transmeta was probably coincidental infringement (in that one can patent the obvious). Transmeta's code morphing was quite different: they were going to VLIW instead of RISCy Pentium Pro operands. It never worked very well, but for the same reason Itanium/Merced failed: it is just really hard to transparently schedule VLIW instructions efficiently without programmer intervention.
    - InclinedPlane 13y ago
      I thought that was what I said, maybe I wasn't very clear. Anyway, it's a really interesting range of problems, as is what's worked and what hasn't. Personally I think code morphing still has a lot of promise, but mostly in software level "emulation"/trans-coding. Something interesting about Itanium is that eventually it's actually become pretty good. But it's now in a market niche that it's not going to be able to break out of. The big problem with IA64, in my opinion, was that they neglected IA32 performance with the first gen. They made the classic error of prematurely committing to a new design before it was proven, which contrasts greatly to the AMD64 example where they did everything possible to ease the transition and maintain, or even improve, performance with x86 only code.
      - angersock 13y ago
        Yeah, our experience with the Itanic is that now that it's finally in port, it's pretty cool--unfortunately, nobody cares.
      - seanmcdirmid 13y ago
        I believe Intel eventually fixed Itanium with more support for dynamic instruction scheduling which sort of goes against the very concept of VLIW. SIMD (via GPUs) rather than MIMD then took the performance crown for HPC tasks and hasn't looked back. VLIW still works very well in DSP-style applications, where static scheduling is quite feasible.
jotm 13y ago
I remember the Crusoe - it was ahead of its time, focusing on low heat and power consumption at a time when TDP meant nothing to the customers...

I was under the impression that they were munched by Intel and basically became the foundation for the microcode that those chips use now. Am I wrong?

masklinn 13y ago
> I was under the impression that they were munched by Intel Nope, you must be thinking about something else. Transmeta started moving into IP in 2005, sued intel for patent infringement in 2006 (settled for a cool 250mil, Intel got a perpetual, non-exclusive license out of it), licensed tech to Nvidia in 2008 and died in 2009 (was acquired by Novafora in January, Novafora collapsed in July but not before Intellectual Vultures made off with the patent stash in Feb) Now part of Intel's activity at the time (the PIII and Pentium M side which ended up with Core) may well have been inspired by Transmeta (as many allege), but at the same time Transmeta's activity best matches Intel's pursuit of the NetBurst (P4) shit-cake, which ran opposite to pretty much anything Transmeta looked for (unless Transmeta had patents on lofty promises they couldn't come close to deliver on, then year the P4 fits).
- angersock 13y ago
  Ah, fantastic. Thanks for the info! Fun fact: TX/RX Labs (Houston Hackerspace) has a rack of old Transmeta blade servers that a former member donated.
- Symmetry 13y ago
  There's speculation that NVidia's Project Denver is an Efficeon reworked to target ARM code rather than x86. So there might be a live Transmeta descendant out in the real world again in a few months. http://anandtech.com/show/7622/nvidia-tegra-k1/2 http://anandtech.com/show/7622/nvidia-tegra-k1/2 http://en.wikipedia.org/wiki/Project_Denver http://en.wikipedia.org/wiki/Project_Denver
InclinedPlane 13y ago
Not at all. The Transmeta is a really fascinating CPU architecture based around "code morphing", modern CPUs use something at a bit of a lower level: micro-op translation.
- seanmcdirmid 13y ago
  Intel was doing micro-op translation way before 2005...it was something they introduced with the Pentium Pro. Their patent problems with transmeta was probably coincidental infringement (in that one can patent the obvious). Transmeta's code morphing was quite different: they were going to VLIW instead of RISCy Pentium Pro operands. It never worked very well, but for the same reason Itanium/Merced failed: it is just really hard to transparently schedule VLIW instructions efficiently without programmer intervention.
  - InclinedPlane 13y ago
    I thought that was what I said, maybe I wasn't very clear. Anyway, it's a really interesting range of problems, as is what's worked and what hasn't. Personally I think code morphing still has a lot of promise, but mostly in software level "emulation"/trans-coding. Something interesting about Itanium is that eventually it's actually become pretty good. But it's now in a market niche that it's not going to be able to break out of. The big problem with IA64, in my opinion, was that they neglected IA32 performance with the first gen. They made the classic error of prematurely committing to a new design before it was proven, which contrasts greatly to the AMD64 example where they did everything possible to ease the transition and maintain, or even improve, performance with x86 only code.
    - angersock 13y ago
      Yeah, our experience with the Itanic is that now that it's finally in port, it's pretty cool--unfortunately, nobody cares.
    - seanmcdirmid 13y ago
      I believe Intel eventually fixed Itanium with more support for dynamic instruction scheduling which sort of goes against the very concept of VLIW. SIMD (via GPUs) rather than MIMD then took the performance crown for HPC tasks and hasn't looked back. VLIW still works very well in DSP-style applications, where static scheduling is quite feasible.

jotm 13y ago

I remember the Crusoe - it was ahead of its time, focusing on low heat and power consumption at a time when TDP meant nothing to the customers...