What happened to Transmeta, the last big dotcom IPO (opens in new tab)

I think this is a classic hill-climbing dilemma. If you start in the same place, and one org has worked very hard and spent a lot of money optimizing the system, they will probably come out on top. But if you start in a different place, reimagining the problem from first principles, you may or may not find yourself with a taller hill to climb. Decisions made very early on in your hill-climbing process lock you in to a path, and then the people tasked with optimizing the system later can't fight the organizational inertia to backtrack and pick a different path. But a new startup can.

It's worth noting that Google actually did succeed with a wildly different architecture a couple years later. They figured "Well, if CPU performance is hitting a wall - why use just one CPU? Why not put together thousands of commodity CPUs that individually are not that powerful, and then use software to distribute workloads across those CPUs?" And the obvious objection to that is "If we did that, it won't be compatible with all the products out there that depend upon x86 binary compatibility", and Google's response was the ultimate in hubris: "Well we'll just build new products then, ones that are bigger and better than the whole industry." Miraculously it worked, and made a multi-trillion-dollar company (multiple multi-trillion-dollar companies, if you now consider how AWS, Facebook, TSMC, and NVidia revenue depends upon the cloud).

Transmeta's mistake was that they didn't re-examine enough assumptions. They assumed they were building a CPU rather than an industry. If they'd backed up even farther they would've found that there actually was fertile territory there.

Wasn't Intel trying to do something similar in Itanium i.e. use software to translate code into VLIW instructions to exploit many parallel execution units? Only they wanted the C++ compiler to do it rather than a dynamic recompiler? At least some people in Intel thought that was a good idea.

I wonder if the x86 teams at Intel people were similarly baffled by that.

The Itanium felt like Intel trying on the same bet - move the speculative and analysis logic into the compiler and off the CPU. But where it differed is that it tried to leave some internal implementation details of that decoding process exposed so the compiler could call it directly, in a way that transmeta didn’t manage.

I wonder how long before we try it again.

Even the people on comp.arch at the time were baffled. No one believed it.

It was risky.

From my perspective it was more exciting to the programming systems and compiler community than to the computer architecture community.

Not completely baffling. Intel made an attempt to create a Transmeta like hybrid software/hardware architecture at the time on one of their "VLIW" processors. It was an expensive experiment that didn't work out.

I recall one of the biggest concerns around the time was that OOOE techniques would not continue scaling in width or depth, and that other techniques would be needed. This turned out to be true, but it was not some fringe idea -- the entire industry turned on this. Intel designed the narrow and less "brainy" Pentium 4 and hoped to achieve performance with frequency, and with HP they designed the in-order Itanium lines. AMD did some speed demon K9. IBM did the in-order POWER6 that got performance with high frequency and runahead speculative execution. Nvidia did a similar thing to Transmeta too, quite a while later IIRC.

All failures. Everybody went back to more conventional out of order designs and were able to find ways to keep scaling those.

I'm sure there were some people at all these companies who were always OOOE proponents and disagreed with these other approaches, but I think your summary has poop colored lenses :) It's a little uncharitable to say their ideas were nonsense. The reality is that this was a very uncertain and exploratory time, and many people with large shreds of cpu arch experience all did wildly different things, and many went down the wrong roads (with hindsight).

Ditzel went to Intel after Transmeta, doing processor architecture.

While I don't know what his group shipped, some implementations of trace caches do store "improved" operation sequences.

what are you doing now? Retired on a farm?

> However, if you add it onto a better CPU it’s a fine technique to bet on - case in point Apple’s move away from Intel onto homegrown CPUs.

I don't think Apple is a good example here. Arm was extremely well-established when Apple began its own phone/tablet CPU designs. By the time Macs began to transition, much of their developer ecosystem was already familiar.

Apple's CPUs are actually notably conservative when compared to the truly wild variety of Arm implementations; no special vector instructions (e.g. SVE), no online translation (e.g. Nvidia Denver), no crazy little/big/bigger core complexes.

Exactly... I think that if you look at the accelerator paths that Apple's chips have for x86 emulation combined with software it's pretty nifty. I do wish these were somewhat standardized/licensed/upstreamed so that other arm vendors could use them in a normalized way.

Would TSMC be further along today, or not, if Transmeta had been thought up five, ten years later? Would Transmeta be farther along for having encountered a more mature TSMC?

TSMC seems to have made a lot of bones on Arm and Apple’s time.

They did! There are many transmeta powered thin clients for example.

I don't know if the bet was even particularly wrong. If they had done a little better job on performance, capitalized on the pains of Netburst + AMD64 transition, and survived long enough to do integrated 3D graphics and native libraries for Javascript + media decoding it might have worked out fine. That alternate universe might have involved a merger with Imagination when the Kyro was doing poorly and the company had financial pain. We'll never know.

Intel was already built on the Pentium at this point. Not as iterable as pure software but decoding x86 instructions to whatever they wanted to do internally sped up a lot of things on its own.

Perhaps they would have been better off building the decode logic as programmable by making effectively a multicore machine where the translation code ran on its own processor with its own cache, instead of a pure JIT.

Folks like to say that, but that's not what's happening.

The key difference is: what is an instruction set? Is it a Turing-complete thing with branches, calls, etc? Or is it just data flow instructions (math, compares, loads and stores, etc)?

X86 CPUs handle branching in the frontend using speculation. They predict where the branch will go, issue data flow instructions from that branch destination, along with a special "verify that I branched to the right place" instruction, which is basically just the compare portion of the branch. ARM CPUs do the same thing. In both X86 and ARM CPUs, the data flow instructions that the CPU actually executes look different (are lower level, have more registers) than the original instruction set.

This means that there is no need to translate branch destinations. There's never a place in the CPU that has to take a branch destination (an integer address in virtual memory) in your X86 instruction stream and work out what the corresponding branch destination is in the lower-level data flow stream. This is because the data flow stream doesn't branch; it only speculates.

On the other hand, a DBT has to have a story for translating branch destinations, and it does have to target a full instruction set that does have branching.

That said, I don't know what the Transmeta CPUs did. Maybe they had a low-level instruction set that had all sorts of hacks to help the translation layer avoid the problems of branch destination translation.

Not to the same level. Crusoe was, in many ways, more classic CISC than x86 - except it's microcode was actually doing dynamic translation to internal ISA instead of operating like interpreter in old CISCs.

x86 ISA had the funny advantage of being way closer to RISC than "beloved" CISC architectures of old like m68k or VAX. Many common instructions translate to single "RISCy" instruction for the internal microarchitecture (something AMD noted IIRC in the original K5 with its AMD29050-derived core as "most instructions translate to 1 internal microinstruction, some between 2 to 4"). X86 prefixes are also way simpler than the complicated logic of decoding m68k or VAX. An instruction with multiple prefixes will quite probably decode to single microinstruction.

That said, there's funny thing in that Transmeta tech survived quite a long way to the point that there were Android tablets, in fact flagship Google ones like Nexus 9, whose CPU was based on it - because nvidia "Denver" architecture used same technology (AFAIK licensed from Transmeta, but don't cite me on this)

Modern CPUs still translate individual instructions to corresponding micro-ops, and do a bit of optimization with adjacent micro-ops. Transmeta converted whole regions of code at a time, and I think it tried to do higher-level optimizations.

Yes, I think the conclusion was that it did improve performance on binaries that were not compiled with optimizations, but didn't generate enough gains on optimized binaries to set of the cost of re-compilation.

https://dl.acm.org/doi/10.1145/358438.349303

(this is not about x86 but PA-RISC, but the conclusions would likely be very similar...)

I believe it was HP who accidentally tried this while making an early equivalent of Rosetta to deal with a hardware change on their mainframes and mini computers. They modified it to run same-same translations and they did get notable performance improvements by doing so.

I’m pretty sure this experiment happened before Transmeta existed, or when it was still forming. So it ended up being evidence that what they were doing might work. It also was evidence that Java wasn’t completely insane to exist.

Notably VMware and alike in pre-hardware virtualization era did something like that to run x86 programs fast under virtualization instead of interpreting x86 through emulation.

There was a Hot Chips presentation by them that also gave some good details. Unlike the original Transmeta design they first ran code natively and only recompiled the hot spots.

Thanks for that, I was almost right - This web page is not here yet.

I still use this as important placeholder text, not that anyone outside HN would get the reference.

It looks like rather than hiring a designer, they let one of their engineers (or worse, the CEO) design the Transmeta logo. I don’t know what that font is, but it might be even worse than Papyrus.

The children of Segway are still here!

Electric unicycles and Onewheels!

And they're really fun!

I seriously doubt that was the problem. The issue was always that these things were essentially a walking aid for the price of a motorbike/small car and were particularly useless in Europe where you had to transverse cobble stone roads or take one onto the metro (good luck with that).

They were a complete hype product, their projections that they would essentially replace walking and pushbikes were just crazy. I don't think I know anyone who wanted one for more than as a toy.

As a side note, at a ee department where I was teaching around 10 years ago, one student build one as his final year project. Pretty awesome, he essentially did everything himself from software to all the mechanics/electronics... Worked very well as well.

In the early 1990s, HP had a product called “SoftPC” that was used to emulate x86 on PA-RISC. IIRC, however, this was an OEM product written externally. My recollection of how it worked was similar to what is described in the Dynamo paper. I’m wondering if HP bought the technology and whether Dynamo was a later iteration of it? Essentially, it was a tracing JIT. Regardless, all these ideas ended up morphing into Rosetta (versions 1 and 2), though as I understand it, Rosetta also uses a couple hardware hooks to speed up some cases that would be slow if just performed in software.

hat was the first laptop i owned ;-) as a frequent traveler it was a very useful device.

Back in the day, Linux was less tolerant of incorrect behavior than Windows 9x was, and would crash, terminate a process, or otherwise surface errors at times when Windows 9x would just keep going until the bugs corrupted memory or similar. Having Linus aboard as a technical advisor, soneone to whom you can say "hey, the CPU is crashing here, what's the kernel trying to do at that spot?", alone, probably would have been well worth the money to hire him.

Nice.

Glad you were a part of it at the time?

> it wasn’t really solving a problem that anyone was struggling with

They did push the envelope on efficiency. My Crusoe-equipped laptop could go six hours on the stock battery (12+ on the extended batteries) back when most laptops struggled to get three.

Transmeta did try to enter the server market. There was a company called RLX Technologies that wanted to use Crusoe chips in blade servers. I remember them demoing a 3U rack server w/ 24 blades in it. 1 CPU per blade.

Wikipedia: https://en.wikipedia.org/wiki/RLX_Technologies

RLX entering the market in 2002: https://www.serverwatch.com/guides/transmeta-1-ghz-crusoe-bo...

RLX exiting the market in 2005: https://www.techmonitor.ai/hardware/rlx_exits_blade_server_b...

They probably would have worked well as server processor, because they were pretty energy efficient, but they were slow the first time a program was run, but sped up after caching the translation. Most servers run the same software over and over again, so they could have been competitive.

It would have been an extremely difficult time to enter the market though, because at the time Intel was successfully paying server manufacturers to not offer superior competing products.

Backwards. The incompetent Transmeta board picked a VP from NVIDIA to be the CEO and his first action was to kill the IBM contract and move to TSMC, and forced TSMC to use a new unqualified process. This left us without chips to sell for over a year and notebook venders were furious and never returned.

This is what killed Transmeta, not all the technical details.

That doesn't make any sense. IBM is the last company that would shut down a fab with no warning, breaking a bunch of contracts.

The Nintendo GameCube and Wii also had IBM CPUs.

I'd imagine so, IBM are many things (some of them brilliant) but I don't think anyone's ever accused them of been cheap.

If their patent portfolio wasn't being used for patent trolling, why is it currently owned by Intellectual Ventures, once called "the ultimate patent troll" by journalists. (https://www.theverge.com/2014/2/4/5375304/intellectual-ventu...)