Transmeta Crusoe | Hacker News Reader

Transmeta Crusoe

en.wikipedia.org

126 points6177c40f100 comments

I worked on that as a QA Engineer. My favorite accomplishment was discovering that one version of a Crusoe-powered system would irrevocably hang while playing Tomb Raider 2 for between 15 and 45 minutes. It took an entire VLSI team over a week to debug that one. The problem had something to do with a voltage drop on a certain chipset.

I also enjoyed discovering that HTTPS didn’t work on Internet Explorer 5.5, jump jets recharged at 10% the expected rate in MechWarrior 2, and a certain modem worked on PCI slots 1 and 3 & didn’t work in PCI slots 2 and 4.

With strange failures like that, I'm surprised the system even booted at all.

Pope was a QA engineer - that means he worked on systems that weren't qualified for shipping. Actual CMS bugs in a shipped device was extremely rare, but the big promise of Transmeta was that would _could_ ship fixes (and did, in at least one case). The perf impact of a CMS fix was typically trivial as it was fixing a translator, unlike an interpreter like the microcode in an Intel core.

I mostly worked on development boards that were the same size that you'd put in a regular AT/ATX case. I did some work on notebooks, too, both on prototypes & production models, too.

I think I know you (Hi!), but my point is that by definition, QA's work is to find the bugs before the customers, so they don't see them. Talking about bugs you find without that qualifier might make people get the wrong impression.

Hola!

One thing to remember is that this dropped circa-2001. The dominant Windows versions were ME and XP.

Both of which featured driver models of... not too much system protection.

So applications (especially games) looked a lot more like their console cousins, in that they took advantage of all kinds of weird hacks and did things 1,000 different ways.

As opposed to now, when you have more strict intermediary layers, and software sits on top of more defined interfaces.

So things like "the MechWarrior developer in charge of jump jets decided to base timing off the PCI bus speed" or god knows what, isn't that surprising.

Thats why I was always skeptical of the Transmeta CPUs. They could 'run' the x86 ISA as its on paper, but they'd never be able to completely match all the nuances of the Intel CPUs to get 100% compatibility. The devils in the details as they say.

Reimplementing an ISA is not actually an impossible feat; many companies have done so successfully before.

Nothing is impossible, but has anybody done it since 2000 starting from scratch? AMD obviously has been at it from the start, Cyrix, VIA, NEC all did it but any since Intel CPUs started being in the tens of millions of transistors?

Hitachi SH-4 | 10M transistors | 1997

SPARC64 V | 191M transistors | 2001

DEC Alpha 21364 (EV7) | 152M transistors | 2003

SPARC64 V+ | 400M transistors | 2004

Cell | 250M transistors | 2005

POWER6 | 789M transistors | 2007

SPARC64 VI | 540M transistors | 2007

SPARC64 VIIIfx | 760M transistors | 2009

16-core SPARC T3 | 1B transistors | 2010

8-core POWER7 | 1.2B transistors | 2010

Quad-core z196 | 1.4B transistors | 2010

SPARC64 IXfx | 1.87B transistors | 2011

SPARC64 X | 2.99B transistors | 2012

8-core POWER7+ | 2.1B transistors | 2012

Apple A7 | 1B transistors | 2013

12-core POWER8 | 4.2B transistors | 2013

Apple A8 | 2B transistors | 2014

Apple A8X | 3B transistors | 2014

32-core SPARC M7 | 10B transistors | 2015

[insert a crapton of ARM CPUs here]

AWS Graviton2 | 30B transistors | 2019

No x86 ISAs in here. All licensed designs or first party manufacturer. I wasn't saying nobody could make anything as complex as current Intel CPUs.

Cloning other ISAs either from clean room or from licensed designs like ARM seems to be much easier than matching Intel CPUs with a massive breadth of software and less hard specifics at the edges.

I used to be skeptical of AMD CPUs & the various motherboards for a long time, too. I figured that Intel had the resources to test the crap out of my computer, and I really needed it to work.

AMD started out and get the designs directly from Intel to make 8086 CPUs on license and continued onto the 286 until Intel broke their agreement and they had to make clean room 386 implementations. So AMD has been doing this since, essentially, the beginning, and have been able to iterate tracking Intel and not starting from scratch in the 2000s with an entirely new approach. They probably could have done it, eventually, but they ran out of funding and thats the end of the road for that adventure.

This statement is pure FUD. There were no meaningful quality issues and the situation is exactly the same for all alternative implementations of the same ISA. You could make the same argument to say that AMD or even a new Intel microarchitecture is incompatible as doesn't have the exact same runtime behavior (eg. shifters on the P4).

The only relevant metric: does it run the applications that customers use.

The Crusoe/Efficeon issues were performance related.

Just as a single data-point: I still had an old Crusoe-based TC-1000 [1] convertible lying around, that must be > 15 years old by now. About two years back I gave it a new hard-disk (some PATA to flash adapter), replaced the battery, upgraded to 768 MB RAM and installed a Devuan i386 OS on it (a Debian derivative). Even was able to make the pen work again (that needed some X-server source code hacks).

The computer is somewhat sluggish with huge software (like Firefox) and especially software that does JIT-compilation, maybe due to limited size of the "code-morphing" cache. For simple java programs the only way to make them start up timely was to fully disable the JIT-compiler.

But other than that it's a usable x86 machine (and all other laptops I know that are of similar age eventually failed to boot much earlier).

[1] https://en.wikipedia.org/wiki/Compaq_TC1000

I had a Transmeta Crusoe powered Windows XP laptop and I never had compatibility issues. Performance issues... that's a different story.

Hah... and I thought this was weird:

https://youtrack.jetbrains.com/issue/JBR-2310#focus=streamIt...

Oh my god! This is why my $4,000 laptop has been crashing!?

Only if you have a 10th generation Ice Lake, which is the 2020 Air and 2020 13" Pro. The 16" has a 9th generation Coffee Lake and does not seem to be affected, so if you have this or an earlier laptop it would have to be something else.

Read the whole thing... it's a ride. Serious WTFBBQ with a side of potato salad.

Once Apple and/or Intel notices this there will probably be a microcode update. Until then if AWS or some other host fields Ice Lake based server cores you may be able to crash the VM host by starting up a Jetbrains IDE in a VM. LOL

The parent post on Transmeta QA shows that obscure bugs causing wacky edge cases are not that rare. It's a function of the complexity of modern chips, especially the X86 lineage with its crazy variable instruction widths and legacy cruft. You can, I think, still boot 16-bit DOS and Windows 3.1 on them!

ARM is intrinsically less prone to this due to simpler pipelines and less cruft, but ARM64 chips are still pretty complex. Any real world chip that has been around for a while is going to grow some hair on it. ARM has some shag but X86 is hairier than a wizened yak.

RISC-V is clean... for now. But there are no really high performance RV chips.

I wonder though... do they not fuzz chips? How do these things escape QA at a serious experienced house like Intel? I can understand obscure security issues slipping by but an a hard crash?

>Read the whole thing... it's a ride. Serious WTFBBQ with a side of potato salad.

Did they rule out GPU driver crashes? They said it also occurs in VM, but didn't specify whether they had any guest integrations enabled.

Also happens on the Surface Pro with the same chip, so unlikely.

There was a bug in the Sony Picturebook w/ a Crusoe in it, I don't remember what the bug was. To isolate it, I drove over to Fry's Electronics and replicated the same exact bug using the Intel flavored Picturebook on the display counter :)

I wonder if Rocket Lake is going to have that bug as well.

Have you considered attaching a kernel debugger, or symbolicating those panics?

The problem had something to do with a voltage drop on a certain chipset.

Did you use any specific stress-testing programs, or just tested with regular applications? Something like the LINPACK benchmark is extremely stressful on the CPU and memory system, and is commonly used today for system stability testing.

I personally just ran whatever I felt like running. We had testing scripts to follow, but I largely ignored them XD My super power was testing things that other people wouldn't normally test. I was good enough at breaking things in unexpected ways that I mostly got away with it.

As somebody who owned both a Crusoe-based and an Efficeon-based machine, let me thank you and your colleagues for the great work you did. I never suffered any stability issues with these machines running various Linux flavours (mostly Debian and Ubuntu).

That sort of detail is fabulous, and reflects really how little we've progressed when it comes down to "brass tacks". Thanks for sharing.

I was on the "silicon level debugging" team, which took test cases like this and boiled them down to x86, then through the CMS to p95 assembler, then down to the circuit and device level to figure out the speed paths. There were definitely some crazy issues we found. Honestly, I couldn't have done that job without relying on 80%+ of my undergrad courses (Computer Engineering @ Waterloo).

The issue I remember the most clearly was one that an engineer Simon Barrett discovered: a specific sequence of MMX instructions would cross-talk (and cause the occasional bit to flip) on two perpendicular busses in the pipeline when run at a specific voltage/frequency. It sounds simple enough, but imagine trying to figure that one out.

The Crusoe was a brave effort that never really lived up to its promise. There was plenty of hype before the release (transmeta.com was, for a long time, a blank page with a hidden message in the source, which combined with them employing Linus left people hugely excited about what they were actually going to make), but what we ended up with was a low power but fairly slow x86 that had some exciting bugs (http://web.archive.org/web/20051202073851/http://www.cs.auc....). In the pre-JIT times, being able to run Java bytecode directly would have been a win, but it doesn't look like that was ever an actual produce and even then it was unclear whether you would have been able to switch between instruction sets at runtime fast enough to support a mixed Java/x86 environment. And before long, Intel had chips that weren't far outside the power envelope but ran much faster.

It's a shame that the would only run signed CMS images - having a laptop you could switch over to running a different architecture would still be a very neat toy.

I was there from 2001 until the end (roughly).

History is written by the winners and outsiders tend to draw technology conclusions based business outcome, which is unfortunate and lacking in nuance.

Crusoe at the time of the release was far more power efficient than anything Intel had to offer and was a revolution to the notebook market. Intel has officially credited Transmeta's LongRun as the motivation for creating SpeedStep.

Performance of Crusoe ("Fred") fell short of the expectations as the approach assumed a faster VLIW core. CMS was very good, but couldn't compensate for the hardware. Had Transmeta not made terrible business screw-ups, the architecture could perhaps have had the iterations necessary the improve the technology. The third generation ("Tokomak") would have been significantly better and almost happened, except for ... business reasons.

IMhO, the original approach has two flaws:

1. Software based interpretation of cold code leads to a dramatic performance difference that can be nearly impossible to catch up to for some applications. IOW, the difference between worst and best performance is much too big.

2. Out-of-order execution is a much simpler and better way to deal with cache misses. The tricks and efforts that went into the architecture to compensate for the in-order execution were mind-boggling and were part of the reason the core was slower than it should have been.

NVIDIA's Denver improved (fixed?) 1. by added hardware acceleration for Arm decoding.

About bad business decisions, I have read that some were made for them by others. They were using IBM as their foundry and a new head of IBM's semiconductor department decided to cancel CMOS to focus exclusively on SOI. Now Transmeta couldn't ship to customers until they did a new design for some other foundry. I have no idea how much this was actually the case.

(edited) Hmm, if that's true it would be news to me. Do you have a reference?

addendum: there's also the fact that Intel deployed many illegal tactics to block Transmeta from selling to customers. This is another large part of why Transmeta failed. It seems entirely plausible that Intel pressured IBM to drop Transmeta as a customer.

Found it (Google didn't help at all) on page 19 of the oral history of David Ditzel at the computer history museum.

https://archive.computerhistory.org/resources/access/text/20...

But I sort of remembered it wrong. Here he talks about having to switch from IBM but in page 16 he talks about the new lab not being able to make chips for a whole year as being the problem.

"In the end, Transmeta didn't make it, and I'll just say here I think it was not because of the technologies. It actually turned out to be manufacturing problems. We switched fabs. The fab we switched to actually had a problem, and couldn't actually make our chips for a year. We had to prove where the issue was in the fab, and what was happening. They're not happy if I speak too much about those details. But, the technology itself worked fine."

That's a very important distinction. The person who made that fatal decision against the objections of many (no, it wasn't Dave) bear much of the responsibility of the death of Transmeta. It was reckless and ultimately a disaster.

In 1999 I set up a company to develop a VLIW processor that used adaptive compilation (but for Smalltalk bytecodes instead of x86 instructions). I was taken more seriously after Transmeta announced Crusoe, then a lot less seriously when it failed. Even though the reasons for that were not technical, everybody remembers it wrong.

Curious, would OoO execution been possible with CMS?

It's complicated enough to resolve things when you're dealing with instructions + hardware execution units.

When that becomes x86 instructions + CMS + native instructions + hardware execution units... it seems a daunting task to hit stability and outlier response targets for the system as a whole.

The whole thing was already incredibly complex: getting the x86 semantics and state right, generating perfectly scheduled P95 code that had the the most useful speculation - while avoiding known hazards in the hardware, etc.

Using a speculative superscalar OoO would migrate part of the complexity from software to hardware. The major concern cited is usually power, but I don't know how much the renamer + scheduler would add relative to everything else; the hardware already had all the rest: extensive speculation support, branch predictors, large register file, store buffers, etc.

It's a fascinating topic and this isn't the ideal forum. However my point is this: there are very few companies out that that tries something truly new, and when one does and fail in the market there too much "told you so" going around.

> However my point is this: there are very few companies out that that tries something truly new, and when one does and fail in the market there too much "told you so" going around.

Absolutely agreed. And from what I hear, the spirit of Transmeta ended up in a lot of other places (either via cleanroom design of similar tech, personnel working on similar projects, or inspiration).

People are also starting to wake up to the just how underhanded and illegal technology companies will behave to squash their competitors, whereas I think the 00s still had rose tinted glasses about the best technical product winning.

This is a little late, but this link is relevant: http://datasheets.chipdb.org/Transmeta/pdfs/Transmeta_Effice...

I had forgotten just how short the pipe was (~ 7 stages!). Going OOO would have added at least one stage.

As someone fairly disjoint from the field of CPU design, I'm curious if there are "processor debuggers/process core dumps" that give you a low-level view of how a certain instruction was executed–how it was translated and reordered, which instructions it had dependencies on, what was in the pipeline and what got invalidated, etc. for bugs like these.

For a fully custom design, the company designing this will develop such tools. No, you can't have it. (And in the case of Transmeta, I'm pretty sure it's all lost now).

My home NIS server is HP T5510 thin client running on Crusoe:

   $ lscpu 
   Architecture:          i586
   CPU op-mode(s):        32-bit
   Byte Order:            Little Endian
   CPU(s):                1
   On-line CPU(s) list:   0
   Thread(s) per core:    1
   Core(s) per socket:    1
   Socket(s):             1
   Vendor ID:             GenuineTMx86
   CPU family:            5
   Model:                 4
   Model name:            Transmeta(tm) Crusoe(tm) Processor TM5700
   Stepping:              3
   CPU MHz:               798.025
   BogoMIPS:              1596.05
   

   t5510 ~ # longrun -p
   LongRun: enabled
   LongRun Thermal Extensions (LTX): active
   LTX setting: 75% reduction
   Current performance window: 0 to 100
   Current performance level: 0
   LongRun flags: economy

Cool! How long has it been running like this?

about more than 5 years now. I bought it used on ebay for 1 Euro.

Do modern Linux kernels still support the architecture, or are you just planning on running it in a configuration "that works" forever?

From the POV of software, it's an x86, not some different architecture. That's the whole point. However, most distributions have stopped supporting x86 (32-bit) and only support AMD64 ("x64", heh).

Ah, yes, I am stupid. Carry on.

No problem...in the future you can change to OpenBSD or NetBSD, they will support x86 'forever'

I worked at Transmeta for a short time (about a year) after my undergrad. I loved it. However, there was always a running joke that the stock ticker symbol should have been “HYPE”. It was sad to see things implode the way they did.

What I remember most about Transmeta was that they employed Linus Torvalds. This gave the name instant status and recognition among the Slashdot crowd and similar places.

The first Crusoe Product was a Sony Picturebook. Somewhere in Japan there’s a prototype of that laptop with Linus’ and others signatures, including mine. It’d be fun to try and track that down someday.

Not in Japan, but I happen to possess a prototype Picturebook and now I'm curious... Where did you sign it? Inside the case like the original Macintosh? Or on the outside?

Gosh, it's been a long time. I don't remember for sure, but I have a faint recollection that I signed it in the O of SONY. But honestly, I don't remember.

the sony picturebook was my first personal laptop. a perfect travelcompanion. once i figured out how to install linux. and the transmeta cpu made it feel special even though as a user one doesn't really notice the difference.

They had a lot of crazy smart employees. Aside from Linus, one of Quake's authors worked there. And I had a Google coworker (who, while at Google, wrote the C++ framework that all their C++ webservers are based on, and also was one of the early engineers on Dart) who was a Transmeta alum, and had previously worked on Hotspot before that.

It's one of those companies like General Magic and Symbolics that were complete failures in the marketplace, but are known for their alumni network. Even though the product didn't go anywhere, the tech that went into the product was incredibly impressive, and the engineers that built that tech are top-notch.

In his book Just for Fun Linus talks a bit about the company and why he chose to work there.

I had one business meeting there, which included Linus and Steve Chamberlain, the creator of Cygwin. It looked like a fun place to work.

That company was cool at the time. Their website was blank but If you looked at the HTML there was a comment saying “this page doesn’t exist” or something to that effect. I decided to see if sending an email to hr@transmeta.com would work and I got a reply and an interview and I was flown out to Sunnyvale. I thought I was the coolest person in the world at the time.

I also remember that something got messed up with my hotel reservation and I mentioned it during my interview and then I heard yelling.

And um... I was still just a college student. It was a different world for me.

That’s how I got the job!

One important piece missing from this story: https://www.extremetech.com/computing/250776-intel-quietly-t...

This brings back memories! I worked for Colin Hunter at Hunter Systems which was the company before Transmeta. It was in a similar space. Their product recompiled DOS 8088 programs--using a similar "dynamic binary translator" as the Crusoe--so they can run on various Unix systems (68k, MIPS) as "native code". I worked on the thing that remapped the video screen memory to VT100 commands so you can see your Microsoft Word on a template.

In a similar space today are these folks who figured out how to built an 8-bit CPU with only 17 TTL chips:

See:

https://hackaday.io/project/165950-cscvon8-an-8-bit-ttl-cpu

This could have been built back in the mid 70s, there was just nobody smart enough to figure it out. It relies on a very simple set of instructions and microcode to implement the instructions of a more capable CPU.

No, we were as smart (if not smarter) in the 1970's but memory was WAY more expensive and the 64 KB the thing uses didn't even exit. Thus, all focus was on getting the most amount of performance out of the fewest bits.

There are plenty of new TTL design like the above that conveniently doesn't work with original constraints.

I spent my hard-earned college freelancing money on a Sony Picturebook with this chipset. It was actually a really nice laptop! 8-ish hours of battery, and tiny. It had WiFi via a PCMCIA card, so it was great for the couch. The screen was really only big enough for a single terminal.

Despite the reputation for instability / bugs, it was actually rock solid running Debian.

See also the most impactful cpu no one's heard of: https://en.wikipedia.org/wiki/NexGen

I used a Fujitsu P2000 Lifebook in college back in ~2001, it was awesome. 6+ hours of battery life (pretty wild for that time) :)

The Lifebook I had could swap the DVD-ROM drive for an extra battery. I literally got 12 hours of battery life which at the time was incredible. It was a much loved notebook.

That's right, I can't remember if I picked up the extended battery. But I do remember it had a modular DVD drive bay and a trackpoint style mouse.

That brings back memories. I loved my Transmeta-powered Lifebook P1120 and used it well beyond its reasonable lifespan: A nine-inch laptop that predated the netbook craze and had a fantastic keyboard. I wish they made a modern version.

Russian Elbrus CPU appears to be a Transmeta on steroids. I am quite skeptical of the things made by Russian Government, but this seems to be a genuinely good device, able to emulate x64 at Core Duo speeds.

Imagine a Beowulf cluster of these babies…

That actually happened.

https://tech.slashdot.org/story/03/11/19/2156246/efficient-s...

I had one of these in a Sharp Actius MM10, and I could write and compile C++ in Visual Studio for most of the day, using the oversized battery. When that time was spent sitting in a coffee shop I'd probably get 3+ people a day asking me about it, due to the size. It was an excellent device, and probably still ahead of its time.

Don't remember verifying with people I used to know that worked at Transmeta, but I recall they originally were going to for performance but then Intel decided to up their game. That's when they decided to push the power angle. Can someone correct me on the specifics?

From another distant memory I remember a story from someone I knew at Transmeta bent over backwards on the Code Morphing Software to get a soft-modem (modem that used the CPU to do some of the work that traditionally would be done in an asic) to work with Crusoe. Sounded like a case of saving $2 on BOM (I'm just making up numbers) in order to get a design win.

... I will say that the original goal was performance, but power efficiency was an [accidental] consequence and that because a focus. It had nothing to do with Intel (other than a general strategy of going after your competitions' weak spots).

Soft-modem story is correct.

I had a Compaq TC1000 which was powered by one of these things. Needed a battery-powered stylus, the keyboard never really could hold up the slate / rest of the computer.

Yet I used it nearly daily at school, since it was considered a 'study aid' because I took notes with the included Agilix journal system that came with Windows XP Tablet PC edition...right up until I discovered this thing called OneNote 2003 and well, let's just say that while the TC1000s themselves are in retirement on the shelf, Onenote is here to stay.

All thanks to that funkily-named processor Transmeta Crusoe .

I remember Transmeta being the stealth startup that was super tight lipped about what they were working on back then. The skinnable instruction set stuff was really cool, but if I recall the only products that really made it to market were laptops with the x86 skin, where the coolest feature of them went largely ignored and they ended up seeing what market success they did because they had reasonable price/power/heat properties for low cost laptops.

The Transmeta Crusoe CPU reminded me of an article I read years earlier about powerful CPUs. The article said the upcoming Pentium would be so powerful you wouldn't need a physical modem it would be emulated in software. That blew my mind that hardware could be emulated inside software.

For many years I had to resist the urge to buy an OQO, which ran on the Crusoe (and you may remember as the handheld PC from the sci-fi series Jericho):

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

Looks like it's GPU is fairly well documented

https://www.youtube.com/watch?v=O1OdaokgXVg

So what you're saying is I'm definitely going to have to buy one, right?

"This page is not here yet." was the Transmeta homepage whilst they were in stealth mode.

I knew a wannabe geek in high school who loved to brag about bullshit for nerd cred. My favorite lie was his boast about his dual core "transmeata crusoe" and how he morphed one of the processors into a 3D accelerator which made a GeForce unnecessary.

I love how young computer people are just like young car people. "My VTEC is connected to my NOX and can run with super high compression, yo!"

That would blow the welds off the intake manifold, especially if you granny shifting instead of double clutching.

Another similar CPU is Nvidia's Denver. It was intended to run both x86 and ARM, but patents got in the way so now it's just ARM. Is there any merit to this design?

I miss my Compaq TC1000. Not for the performance but because it felt like I was "using the future" between the relatively novel 2-in-1 format and the CPU.

I have a Fujitsu P2110 with the Transmeta Crusoe CPU. It was passed along by a friend who had upgraded to a more powerful machine but didn't want it to go into the trash. She said it was "slow slow SLOW".

Well, yes. The machine had 256MB RAM, and the Crusoe grabbed 16MB off the top for code morphing. It came to me with WinXP SP2. XP wants 512MB RAM minimum to think about performing. It took 8 minutes to boot, and longer to do anything once up. It did a good job of emulating classic mainframe "death by thrashing" You could get a daughter card to add 128MB RAM, but that wouldn't help in this case. (There was another daughter card for an earlier Fujitsu model that added 256MB, but I couldn't find confirmation it worked in the P2110.)

I treated it as an experiment to see what performance I could coax out of low end hardware without throwing money at it. I swapped in a drive from a failed laptop, repartioned and reformatted, and set it to multi-boot. Win2K Pro SP4 actually ran, more or less, on the P2110, especially after I took everything out of startup that could be removed. I also installed two flavors of Linux - Ubuntu and Puppy, and FreeDOS.

Puppy was designed for low end hardware, and Puppy itself worked well enough. Applications didn't. The speed bump was apparently the IDE4 HD. IDE4 was a BIOS limitation, so swapping in a faster drive wouldn't assist.

Installing Ubuntu was a challenge. Xubuntu downloaded and installed, but performance was snail slow. Posters on the Ubuntu forums said too much Gnome had crept into Xubuntu, and Ubuntu had a steadily increasing idea of what "low end" was. The recommended what I did - DL the Minimal CD and install from it. That would give me a working bare bones CLI installation, and I could use apt-get to pick and choose what else got added. Lubuntu got the nod as desktop GUI, and worked, though it was noting I'd call speedy.

Puppy and Ubuntu were both installed on ext4 file systems, and mounted each other's slices when they booted. I spent some time arranging things so there was one copy of large apps shared between them.

FreeDOS flew. The challenge with it was to get it to boot from grub2. I did, but have no idea which of the fiddles I tried actually made it work.

Ubuntu provided another quirk. A new Ubuntu release came out. This one required PXE. The P2110 didn't have it. Installation proceeded normally, but things went to hell in a bucket when I reboted after install. Lack of PXE made installation of the new kernel fail, and that caused a cascade failure. I had to wipe the Ubuntu FS slice and redo from scratch, carefully stopping at the last release that worked and staying put. A test in the installer to insure that PXE was present before continuing and refusing to upgrade if not would have been nice. I assumed the Ubuntu folks just never imagined someone would try to install on a machine that lacked it.

I got surprise email from a woman in Hong Kong who also had a P2110. She got the 256MB RAM expansion card, it worked, and she was running WinXP with acceptable performance. I tipped my hat in respect, but had retired the P2110. I was an experiment, the experiment was completed, and actual work got done elsewhere.

I still have the machine, but haven't booted it in ages.

I was the last engineering employee of Novafora, which bought Transmeta. Shortly after, both were wound down.

Intel bought all the IP in a private auction for about $200k. (I was the other bidder, and hoped to Open Source the EDA tools.) The files were on a single old server, so not sure if anything still exists.

I own the tapeout server (CS22 - quad-CPU Opteron with 64 GB RAM) used by both companies, which I plan to donate to the Computer History Museum.

Transmeta only used AMD servers for some reason, I guess it was because they felt they were in competition with Intel. Kind of like how grocery stores don't want to use AWS because it would "pay the competition" (Amazon owns Whole Foods.)

How strong is the IP position around the CMS?

So did they get bought out by the NSA or something? It's weird how the whole company and everything else just disappeared.

This seems like the exact same story as Magic Leap among others.

No, not at all. Transmeta got a lot closer to nailing a much bigger market. They had actual products for a start. The problem was the underlying architecture was VLIW. Lots of people including Intel and Nvidia have tried to make it work and have been squarely bitten in the arse.

And the failure of Transmeta was a business failure far more than a technical one. Had we not switched from working chip produced on IBM's fab, we would have had chips to give our customers who would have kept giving us money to invest in improved products ...

EDIT: wording & typos

Now Russians (more precisely, Russian Government) are trying to use VLIW. Elbrus CPU seems to be an interesting device, able to emulate x86 at Core Duo speeds.

FYI. МЦСТ, a developer of the E2K CPUs has recently published an "Effective Programming of Elbrus CPUs" guide which describes its ISA. The document is in Russian.

Link: http://www.mcst.ru/files/5ed39a/dd0cd8/50506b/000000/elbrus_...

Intel was later more successful with VLIW. They bought Silicon Hive a company in NL that built VLIW for image processing. I had left by then but my understanding is that they were able to build actual products with it.

I think they were referring to Itanium.

Reply on news.ycombinator.com