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.
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.
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.
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.
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.
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).
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.
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.
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.
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?
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).
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?
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 :)
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).
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.
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.
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 ...
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.
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 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 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.
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).
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.
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:
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.
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 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.
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).
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.
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.
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 .
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.
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):
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.)
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 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.
102 comments
[ 1.7 ms ] story [ 164 ms ] threadIt'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.
And um... I was still just a college student. It was a different world for me.
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.
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.
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.
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."
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.
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.
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.
I had forgotten just how short the pipe was (~ 7 stages!). Going OOO would have added at least one stage.
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.
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.
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
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.
The only relevant metric: does it run the applications that customers use.
The Crusoe/Efficeon issues were performance related.
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
https://youtrack.jetbrains.com/issue/JBR-2310#focus=streamIt...
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?
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.
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.
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.
EDIT: wording & typos
Link: http://www.mcst.ru/files/5ed39a/dd0cd8/50506b/000000/elbrus_...
Despite the reputation for instability / bugs, it was actually rock solid running Debian.
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.
There are plenty of new TTL design like the above that conveniently doesn't work with original constraints.
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.
Soft-modem story is correct.
https://tech.slashdot.org/story/03/11/19/2156246/efficient-s...
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 .
https://en.wikipedia.org/wiki/OQO
https://www.youtube.com/watch?v=O1OdaokgXVg
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.)