The i860 I think originally had a mode. But they then went ahead and doubled down on Itanium.

The discussions on comp.arch from that era are a gold mine. There were lead architects from the P4 team, from the Alpha team, Linus himself during his Transmeta days... all talking very frankly about the concerns of computer architecture at the time.

Adjacent but not the same bet.

EPIC aka Itanium was conceived around trace optimizing compilers being able to find enough instruction level parallelism to pack operations into VLIW bundles, as this would eliminate the increasingly complex and expensive machinery necessary to do out of order superscalar execution.

This wasn't a proven idea at the time, but it also wasn't considered trivially wrong.

What happened is that the combination of OoO speculation, branch predictors, and fat caches ended up working a lot better than anticipated. In particular branch predictors went from fairly naive assumptions initially to shockingly good predictions on real world code.

The result is that conventional designs increasingly trounced Itanium as the latter was still baking in the oven. By the time it was shipping it was clear the concept was off target, but at that point Intel/HP et all had committed so much they tried to just bully the market into making it work. The later versions of Itanium ended up adding branch prediction and more cache capacity as a capitulation to reality, but that wasn't enough to save the platform.

Transmeta was making a slightly different bet, which is that x86 code could be dynamically translated to run efficiently on a VLIW cpu. The goal here was two fold:

First, to sidestep IP issues around shipping an x86 compatible chip. There's a reason AMD and Cyrix are the only companies to have shipped intel alternatives in volume in that era. Transmeta didn't have the legal cover they did, so this dynamic translation approach sidestepped a lot of potential litigation.

Second, dynamic translation to VLIW could in theory be more power efficient than a conventional architecture. VLIW at the hardware level is kinda like if a cpu just didn't have a decoder. Everything being statically scheduled also reduces design pressure on register file ports, etc. This is why VLIW is quite successful in embedded DSP style stuff. In theory, because the dynamic translation pays the cost of compiling a block once then calls that block many times, you could get a net efficiency gain despite the cost of the initial translation. Additionally, having access to dynamic profiling information could in theory counterbalance the problems EPIC/Itanium ran into.

So this also wasn't a trivially bad idea at the time. Transmeta specifically targeted x86 compatible laptops as that was a bit of a sore point in the Wintel world at the time, where the potential power efficiency benefits could motivate sales even if absolute performance still was inferior to intel.

From what I recall hearing from people who had them at the time, the Transmeta hardware wasn't bad but had the sort of random compatibility issues you'd expect and otherwise wasn't compelling enough to win in the market vs Intel. Note this was also before ARM rose to dominate low power mobile computing.

Transmeta ultimately failed, but some of their technical concepts in detail have been continued on in how language JITs and GPU shader IRs work today. Or how Apple used translation to migrate off both PowerPC and x86 in turn.

In both the case of Itanium and Transmeta I'd say it's historically inaccurate to say they were obviously or trivially wrong at the time people made these bets.

Itanium wasn’t really focusing on running x86 code. Intel wanted native Itanium software, and x86 execution was a bonus.

No, Transmeta was never a big or significant player. ARM was started in 1985 and Apple was an early meaningful investor. By the turn of the millennium ARM was already well established in the microcontroller, PDA and cell phone space (smartphone and feature phone). Ten years later you already had the iPhone well established. It was just never going to happen for them. TSMC made bones on being a fabricator for all sorts of custom chip designs. It almost didn’t matter who it was as long as there was increasing volume.

And UMPCs. Sony made at least one of the PictureBooks with a Transmeta CPU and IIRC their U1 used it as well.

When you are operating at that level, there is a lot of similarity between software compiled to machine code, and software compiled to a chip design. The differences are that the machine code comes with some extra overhead, and changing chip designs takes more work.

Fundamentally Transmeta to make iterations of designs quicker, at the cost of some performance overhead. What Intel chose that extra low level performance, at the cost of overhead on iterations. And then Intel made up for the extra cost of iterating designs by having more resources to throw at the problem.

If Transmeta had equivalent resources to throw at their approach, they would have likely won. But they didn't. And I think that they made the right choices for the situation that they were in.

Incidentally the idea of programmable microcode on top of the CPU was not original. It was used in all sorts of software systems before them. Such as Java. The first big use that I'm aware of was the IBM 360, back in the 1960s. There are still programs running on mainframes today that fundamentally think that they are running on that virtual machine from the 1960s!

We’re all retired in some sense. Some on farms, some elsewhere. But in a broader and deeper and more meaningful level, we’re not retired at all…working harder than ever.

I don't either. Even with their problems, they didn't miss by much.

One key factor against them, though, is that they were facing a company whose long-term CEO had written Only The Paranoid Survive. At that point he had moved from being the CEO to the chairman of the board. But Intel had paranoia about possible existential threats baked into its DNA.

There is no question that Intel recognized Transmeta as a potential existential threat, and aggressively went after the very low-power market that Transmeta was targeting. Intel quickly created SpeedStep, allowing power consumption to dynamically scale when not under peak demand. This improved battery life on laptops using the Pentium III, without sacrificing peak performance. They went on to produce low power chips like the Pentium M that did even better on power.

Granted, Intel never managed to match the low power that Transmeta had. But they managed to limit Transmeta enough to cut off their air supply - they couldn't generate the revenue needed to invest enough to iterate as quickly as they needed to. This isn't just a story of Transmeta stumbling. This is also a story of Intel recognizing and heading off a potential threat.

Amplia Pro, maybe.

https://www.myfonts.com/collections/amplia-pro-font-jonahfon...

The Dynamo project was the genesis of a similar effort at Sun Microsystems which was the genesis of Transmeta Corp (all founders came from Sun). The question remains if the original study was flawed or if the situation was just too different for our x86 workloads.

He was also one of the world leaders at the time of people who understood x86 privileged space like the back of their hand, and hadn't signed any AMD or Intel NDAs. Linux was originally designed not to be portable, but as a platform for playing with 386 privileged mode constructs. Portability came later (with Alpha IIRC).

Thank you for correcting me. I don't know where I heard the story I mentioned.

My job was essentially playing videos games for two years to stress test the chips. I was pretty good at Diablo 2 by the end of my run :) It was one of my better jobs!

It was my first sub-notebook, coming from a thinkpad 600e, and though my memory is fuzzy from 20+ years ago, I think I used an atheros wifi pcmcia/cardbus? card with it at some point. It was also awkward some times having to carry their external 3.5" floppy drive too.

You answered that yourself, didn't you? You first said that Transmeta became a patent troll. But the one doing the trolling (a word related to "trawling") is Intellectual Ventures. Not Transmeta, the latter did actual work and did create products.

So intellectual ventures - notably a different company than transmeta - is being a patent troll. That means transmeta became a patent troll too?

Why should I believe what you say anyway? Wendy Verlander - notably a different person than you - is a well known patent troll. That means you are just another patent troll not worth my attention. (At least according to your reasoning).

> 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.

Fixed guest branches just get turned into host branches and work like normal.

Indirect guest branches would get translated through a hardware jump address cache that was structured kind of like TLB tag lookups are.

This is not true. x86 CPUs have long had micro-op caches that support taken branches which do not result in icache fetches. Probably started with Pentium4's trace cache which was perhaps a little more similar to Transmeta's design, but modern x86 CPUs from Intel and AMD both do dynamic translation from x86 to an internal instruction format that includes branches and likely has some transformation (e.g., some fusion and perhaps cracking).

The motivations and mechanics and performance characteristics are all very different than what Transmeta did, but still it is difficult to argue that modern x86 CPUs do not translate x86-64 into their own internal instruction sets even if you have this branching requirement.

> 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).

Except "the cloud" at that point was specifically just a large number of normal desktop-architecture machines. Specifically not a new ISA or machine type, running entirely normal OS and libraries. At no point did Google or Amazon or Microsoft make people port/rewrite all of their software for cloud deployment.

At the point that Google's "bunch of cheap computers" was new, CPU performance was still rapidly improving. The competition was traditional "big iron" or mainframe systems, and the novelty was in achieving high reliability through distribution, rather than building on fault-tolerant hardware. By the time the rate of CPU performance improvement was slowing in the mid 2000s, large clusters smaller machines were omnipresent in supercomputing and HPC applications.

The real "new architecture(s)" of this century are GPUs, but much of the development and success of them is the result of many iterations and a lot of convergent evolution.

That’s revisionist. Transmeta set out to write a software like cpu core. That will always lose to dedicated hardware.

> Well we'll just build new products then, ones that are bigger and better than the whole industry.

With blackjack, and hookers!

Not revisionist I think just more that a lot of people first encountered the concept with the story of Google and don't know it had plenty of precedent.

> Many common [x86] instructions translate to single "RISCy" instruction for the internal microarchitecture

And then there are read-modify-write instructions, which on modern CPUs need two address-generation μops in addition to the load one, the store one, and the ALU one. So the underlying load-store architecture is very visible.

There’s also the part where we’ve trained ourselves out of using the more CISCy parts of x86 like ENTER, BOUND, or even LOOP, because they’ve been slow for ages, and thus they stay slow.

>something AMD noted IIRC in the original K5 with its AMD29050-derived core

Just a small nitpick: I've seen the K5/29050 connection mentioned in a number of places, but the K5 was actually based upon an un-released superscalar 29K project called "Jaguar", not the 29050, which was a single-issue, in-order design.

That wasn’t an HP product. It was written by Insignia Solutions and ran on multiple platforms.

I had it on my Mac LCII in 1992. It barely ran well enough to run older DOS IDEs for college. Later I bought an accelerator (40Mhz 68030) and it ran better.

https://en.wikipedia.org/wiki/SoftPC

Apple Arm CPUs have some special tricks to make x86 sogtware emulation faster.

https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f...

Yes, but wasn’t most of that because its performance was low? If you had dialed back the performance of an equivalent Pentium (model whatever was current at that time), would it have been in the same power ballpark?

Yeah, for me Segway has been a great lesson in how patents can hold back innovation. It was a niche player that prevented others from trying to innovate on the form factor for a number of years.

> Self modifying code is handled with MMU traps on the writes, and invalidation of the relevant traces. It is very much a slow path though. Ideally heavy self modfying code is able to stay in the interpreter though and not thrash in and out of the compiler.

This might end up having a bad time running JavaScript VM JITed code, which self-modifies a lot.

But all of that makes sense! Thanks!

I think your focusing on the details and missing my broader point - the JIT technique for translation only works to break out of the instruction set lock-in. It does not improve performance, so betting on that instead of super scalar designs is not wise.

Transmeta’s CPU was not performance competitive and thus had no path to success.

And as for Apple itself, they had built the first iPhone on top of ARM to begin with (partially because Intel didn’t see a market). So they were already familiar with ARM before they even started building ARM CPUs. But also the developer ecosystem familiarity is only partially relevant - even in compat mode the M1 ran faster than equivalent contemporary Intel chips. So the familiarity was only needed to unlock the full potential (most of which was done by Apple porting 1p software). But even if they had never switched on ARM support in the M1 the JIT technique (compiled with a better CPU and better unified memory architecture) would still have been fast enough to slightly outcompete Intel chips on performance and battery life - native software just made it 0 competition.

> no special vector instructions (e.g. SVE)

Wut - SVE and SME are literally Apple designs (AMX) which have been "back ported".

> ARM from then vs the one that was in phones shares little in terms of useful experience

There seems to be a fair amount of continuity.

For example, Acorn's RISC OS (1987 onward) was ported to the modern Raspberry Pi, and you can still write ARM assembly language in your BBC BASIC programs on RISCOS for the Pi.