4 ms·

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 blan

by mjg59 6y ago

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.dk/~fleury/bug_cms/ 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.

FullyFunctional 6y ago
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.
- jecel 6y ago
  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.
  - FullyFunctional 6y ago
    (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.
    - jecel 6y ago
      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/2016/07/102737949-05-01-acc.pdf 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."
      - FullyFunctional 6y ago
        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.
saagarjha 6y ago
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.
- FullyFunctional 6y ago
  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).
- deleted 6y ago
  [deleted]

by mjg59 6y ago

FullyFunctional 6y ago

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.

jecel 6y ago
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.
- FullyFunctional 6y ago
  (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.
  - jecel 6y ago
    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/2016/07/102737949-05-01-acc.pdf 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."
    - FullyFunctional 6y ago
      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.

saagarjha 6y ago

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.

FullyFunctional 6y ago
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).
deleted 6y ago
[deleted]