Slashdot Log In
UPDATED: Transmeta's Crusoe Unveiled
from the rolling-it-out dept.
There's two chips:
TM3120
- Scales to 400 mhz
- .22 micron process
- 73 die-type
- Released: Now
- $65-89
PM5400
- Scales up to 700 mhz
- .18 micron process
- 73 die type
- Released: Mid-2000
- Projected Pricing: $119-329
The chips themselves are 128-bit chips, and are aimed at the mobile market, as TM has said before. One of the incredible parts is their power consumption: 20 milliwatts of power in deep sleep, and 1 watt of power in regular usage. They've written their own BIOS, with Power Management on the chip called "LongRun". The chip actually gauges how much of the processing power that is needed and adjusts the power accordingly, meaning a much longer battery life.
The thermal difference is cool, too - the Pentium III is 113 Celsius, while Crusoe runs at 48 Celsius. That means no fans needed, another power saving move. And my lap won't be as warm. They're aiming this at everything from cell phones to laptops. At this time, they've said that samples have been shipped to "leading notebook vendors" but have declined to name them. As they've said before, IBM is making the chips for them.
What Linus has been doing: He's been writing a version of Linux called "Mobile Linux". It's written into the ROM and you can use the machine through a touchpad screen. The IDE and everything will be released to the Community. Yes, Linux has gone even more mobile. Oh - and Dave Taylor & Linus played Quake to demo it. Linus lost.
The x86 emulation is done at the hardware level - although emulation is the wrong word. We'll have more information on that as well.
We'll be updating this story - the press conference is still going on, but I figured people would want to know. This looks amazing. Check out ZDNet's tech coverage.
UPDATE by David Cassel
What I Saw At the Revolution
Transmeta rented an auditorium on an estate 20 minutes from their headquarters -- and everyone was excited. Walking through the rain -- past the huge lawn, the PacSat satellite uplink, and guys in suits talking into cellphones -- was Transmeta manager Rob Bedichek, who worked on Crusoe's dynamic translator. I asked him how he liked working at Transmeta, and he told me "The first couple of years," I'd wake up and I'd go, 'I have the most fun job in Silicon Valley." On the way into the auditorium I asked him about about the company ("The people I work with are amazing: people whose work I'd read about as a grad student.") and Linus. ("Great guy. Very capable.")
Transmeta had packed the press into an auditorium known as the "carriage house" -- I saw a dozen TV cameras, and I'd guess 150 reporters. A big screen filled part of the wall by the stage, flashing a fast montage of pictures (circuit boards, people's faces) over cheesy jazz music. But when Transmeta CEO David Ditzel took the stage at 9:05, there was a dead silence. "I know some of you have been waiting a while to hear about what we've been doing," he said to play up the tension, prompting a few laughs. "Some of you have been waiting four and a half years..."
Ditzel ran through his Power Point Presentation. (1995. "Something was fundamentally wrong with processors...") and pointed out that the people looking for solutions had been the entrenched semi-conductor companies. Then he announced, of course, Transmeta's "combined hardware/software solution.... The first microprocessor re-thought explicitly for the problems of mobile computing." By now everyone knows that it retains x86 compatibility while allowing a a completely new chip architecture. Ditzel remembered that when he was recruiting for Transmeta, after sharing his plans he'd hear, "If you start this company, I'll quit my job and come join you to do this.
Ditzel ticked off the specs, using phrases like "dynamic translation" and "software-optimized execution," and pointing out that only one-quarter of the functionality would be on the Crusoe chip itself. And there were frequent mentions of the mobile Linux operating system. (More about that later.) Wednesday's announcement was just the first two chips in the Crusoe family: the TM3120 (with 400 Mhz, 108 KB of cache, using 1 watt of power) and the TM5400 (700 Mhz, 400 Kb cache, and 1 watt of power.) Towards the end, Ditzel demonstrated a WebPad -- running Linux -- and pointed out that today's notebooks still use chips designed for servers and desktops. Then he staked his claim. "If it has a battery and a Web browser, it's going to be built with Crusoe."
Ditzel had to stress details for business reporters -- "significant staff" in Taiwan and Japan and "a very strong partnership with IBM -- and later Doug Laird, Transmeta's VP of Product Development, described IBM as "Great guys" and added, "We are in production right now." But I liked one of Ditzel's last comments: "Our goal is to fundamentally change the rules."
Doug Laird was more intense, arguing with current benchmarks ("Today's benchmarks address performance and battery life separately") and promising to show "what is fundamentally different here... Where's the beef." Using a red laser pointer, he ran through taped footage of a system running MS Word 2000 and Excel 2000 on a system with a Crusoe chip, "translating on the fly, as you're running the programs." Then he displayed thermal images comparing processors. (Sensing a photo-op, the cameras started flashing when he held up two "thermal solutions" and started talking about fans...) Laird made his point by showing a Crusoe system using less than 2 watts of power while playing a DVD and pointing out that it can adjust from frame to frame. (The audience laughed at the PowerPoint movie that showed two laptops playing a DVD. Two thermometers showed the temperature rising; then the laptop on the right started smoking...)
Then to break things up, there was the historic Quake showdown between Quake co-creator David Taylor and Linus. "I can't think of anybody better on the face of the planet to demonstrate Crusoe on Linux than Linus Torvalds," Laird joked. The photographers rushed towards the stage again for the even-more-obvious photo-op as Linus came out in his denim shirt, jeans, and sandals. ("I'd like to point out that if I lose, it's not the operating system," Linus joked.) It all ended when Linus fired all his bullets in a spray, then got nailed when he ran out of ammo. (Later in the press conference, after a bunch of questions about his role and Transmeta, Linus referred back to the Quake game, saying it was "meant to show that I'm here, but I'm not supposed to be the main point of it all.") One of Transmeta's technical staffers told me at lunch that "We all knew Linus was gonna get his ass kicked," and sure enough, when I asked Dave Taylor what he thought of Linus's Quake-playing, he said "I thought he sucked." But then he added modestly "I suck at code compared to him. So that felt good."
After the Quake match, the scripted presentation ended and the open press conference began. Linus had worked on the code morphing, but he wasn't one of the execs in this first round of questions. Still, he was clearly on people's minds. Almost immediately a reporter asked what Linus's role was at Transmeta, and then Boardwatch's Thom Stark drew a laugh when he asked when Transmeta would open source the code morphing software. (Since it's considered part of the chip's intellectual property, they probably won't.) And Mark from Linux Journal asked why everything had been so tightly guarded, arguing "There's no demand for secrecy."
Ditzel's answer was that he'd learned the difference between hype and buzz. ("Buzz is when you're quiet and someone else talks about you.")
Rob Bedichek told me later they were proud to have not made promises until they had something to show -- and David agreed. "You've heard what we have here. Today." Right before lunch, Rob remembered that it had been like working on the Manhattan Project. "You don't talk."
The audience wasn't easy. Two back-to-back questions raised the issue of benchmarks (which are answered extensively on Transmeta's Web site) and PC Week asked where their OEM's were. But Ditzel did a good job fielding the questions. He stressed that this announcement had intentionally left out OEM's, to focus attention on the chip itself -- and VP of Marketing Jim Chapman joked that anyways, "I don't think 'contract' is a germane word in the PC industry."
In fact, Ditzel was really building up momentum. I asked him what had happened in early 1998 -- when he was quoted as saying "We had a major change in direction a few months ago, and that has slowed us down a bit." His immediate answer drew applause, and probably the biggest laugh of the morning. "That was just something to throw off reporters.
I'm not sure if he was referring to the same period, but when Linus came on later he mentioned that the first chip didn't perform as well as they'd hoped. But thanks to the code morphing software, "one of the advantages is being able to change the way the chip works..." After some early bugs, "We were able to tell our translation software: Don't do that." He pointed out the chip could easily handle something like the Pentium's famous long-division bug. "Maybe we will have a bug -- but at least we can fix it."
Anyway, at this point, Ditzel was building up so much momentum that the next question was just, "Ask the President to say something." (Mark Allen had been introduced as the new president and CEO for Transmeta, hired just two weeks earlier.) There was a laugh when Ditzel aced the question about expected chip volume. (Was it hundreds of thousands or millions? "Yes.") Chris DiBona asked about the size of the marketing and sales organization (25 people) and as things were wrapping up, someone asked the obvious question about running Windows: does Crusoe *improve* the stability? Ditzel's answer? "If you get a blue screen on another chip, we'll reproduce that faithfully."
Later they brought out Linus, Bill Roses from the code morphing division, Doug Laird again, and three other technicians for the "Engineering Press Conference" -- but during the break, I talked to Rob Bedichek some more. "I'm totally pumped, totally pumped," he said. "This is a big mountain to climb." So how did they do it? "With an unbelieveable team. And an unbelieveable amount of money." (I said I'd heard $100 million, and he said "Well north of that.") Reporters were everywhere -- mulling in clusters out of the rain.
"What do you think of this stuff?" I heard one ask another.
"I think they fixated on a market that's not being well-served."
One of the first questions in the Engineering Press Conference was for Linus, about the mobile Linux operating system that kept coming up in the presentation. It's a "small distribution to give to OEM's so they could have something to run with....not a Transmeta Linux, but more of a vehicle for supporting OEM's." (Rob told me later, "We recompiled Linux for our machine. There's no advantage!") Later Linus added that "It looks a lot better this week than it did last week," and that it "needs some work..." ("Like the chip, we're not releasing anything until it's ready.") Naturally, he specified that it will be Open Source. Someone asked him if his Transmeta job would affect kernel development. "My interests have always affected kernel development," he pointed out. "That's not gonna change."
Linus also talked about how much he liked mobile computing, saying he loves his Gateway but that it takes forever to boot. When asked about how he'd decided to come to work for Transmeta, he described the presentation Transmeta had given him. "I went back to the hotel room and I thought, 'These people are crazy.' And that was a positive reaction. Despite the simulations they showed him "at glacial speed," Linus wanted to work for "a company that does something for and something interesting."
So what were the other job offers that he'd had? Linux companies, of course, Linus answered, but "I didn't want to polarize the Linux market." And Transmeta is a good solution. "We were a chip company where Linux is part of a much larger strategy."
Then he asked the reporters, "Do you have questions for someone else?" (No real surprises; except Bill Roses conceding that Mac compatibility was "theoretically possible.")
When it was over, reporters milled around for the free lunch or crowded into the next building to play with the demo equipment. Basically it was boxes showing the Crusoe chip's ability to run existing software. (There was a Windows 2000 box running Office 2000, next to a Linux box running Quake) and some blue laptops in front of cards that said things like "Ultralight Mobile". But towards the end Transmeta VP of Software Engineering Colin Hunter did show me a neat WebPad using Transmeta boards and software and IDEO mechanicals which let you plug-in attachments for games and cameras.
And with that, as the press release said, "Transmeta breaks the silence."
Emulators (Score:4)
Crusoe News Article Links (Score:4)
MSNBC: http://www.msnbc.com/news/358517.asp [msnbc.com]
ZDNet: http
CNN: http://www.cnn. com/2000/TECH/computing/01/19/crusoe1.idg/index.h
BTW, Arstechnica is promising an in-depth look at the CPU later today from their CPU expert.
Hrmm... (Score:3)
Will this chip have the same hard time to enter the market?
Here's a thought (Score:3)
low-cost. This is all very, very good.
Given the mention of the "touchpad screen", is it possible that a Crusoe/MLinux system would
be able to serve as the basis for kiosk-class systems, like ATM machines, information stands,
and so on and so forth?
If the chip is that cheap, and the OS is free, wouldn't it sort of make sense to harness that
and direct it towards those sort of ubiquitous consumer machines that you are starting to see all over the place?
Chris Tembreull
Web Developer, NEC Systems, Inc.
My opinions are my own, and nobody else's.
History (Score:4)
What is does under the hood, between it's translation of instructions and its optimization of the actual code (profiling on the fly), is phenomenal.
This information is not correct (Score:4)
no release of the vliw instruction set? (Score:3)
While this is a good thing in one sense it means
we're limited to only the code morphing software they want to release (since that's native).
So if they don't release code morphing software for PPC, or MIPS or SPARC or ALPHA then you're SOL, you can't write it. And may also be difficult or impossible to write a native version of linux.
Anyone have any thouhgts on this?
Webcast notes (Score:3)
Re:The Webpad (Score:3)
The Real fun is in the possibilites.. (Score:3)
For example, a Motorola G4 instruction set software piece could pave the way for someone to sell a handheld/mobile Mac!
Amiga faithful could potentially see a handheld Amiga with a 68000 instruction set component!
Heck, now that I think of it, arcade games these days use various RISC processors, imagine going to an arcade, and renting the use of a handheld arcade game!
Fascinating stuff, I have to say. Fascinating.
no linux on the 700Mhz version? (Score:3)
it was mentioned near the end that the vliw instructions AND the code morphing software on the two chips are different and NOT binary compatible.
So possibly no Linux on the 700Mhz version?
(they said it's optimised for 16 bit x86 instructions)
Relative performance? (Score:5)
I see that this processor comes in two versions with different Mhz, but what does that actually mean in real world performance? What is a 700Mhz or 400Mhz Crusoe chip equivalent to? As we all
know, the Mhz rating does not mean everything.
-OT (bogomips for everyone!)
Mobile Linux (Score:4)
Hotnutz.com [hotnutz.com]
Re:Lots of great information here (Score:4)
Think about it. If it's x86 compatible, what does he need to do? Combine the knowledge that he's doing 'something' with the knowledge that it's portable/embedded/low-power, and right there you've got a pretty good picture of the market Transmeta is going for; other's could have moved to cut them off at the pass.
So he *had* to say that his job wasn't Linux-related. To do otherwise would have been to tip Transmeta's hand.
He did give us enough clues, though. In every interview I've read in the last 9 months, he's mentioned how interested he was in the embedded market, and how cool it would be to see Linux going in that direction.
Don Negro
Excitement with reservation (Score:3)
My concerns are this:
since it is maintaining compatability with x86 instruction sets, it will always follow Intel's lead (and require Intel to continue leading) mainstream chip technology.
It will never run as fast as a native x86 chip would (because it must execute extra instructions). Of course, being smaller and independent to the hardware, these chips may be made significantly faster (clock-wise) than mainstream CISC/RISC chips and comparatively match performance. But not yet.
No mention was made regarding the connection to the Internet...that was just assumed to be there. But I have yet to hear about any affordable and sufficiently fast connection via mobile unit... How will they address this, or will they just leave it up to other companies to solve this general problem?
Transmeta touts Internet Compatibility, but the low end Internet appliances are specifically designed to work with Linux. However, Linux does not have a standards-conforming browser (i.e. IE) available until Mozilla is complete. Will Transmeta help push Mozilla to completion? The specific mantra was, "You have to run the cool site of the day" but many sites are becoming dependent on HTML 4, CSS2, DOM2, ECMAScript 2, etc., which, sorry, only are supported to any extent by IE5. How will Transmeta maintian "Internet Compatibility" with Linux-running machines?
One correction to Hemos, however, Transmeta specifically said they are not targeting cell phones and Palm Pilot-type machines, but rather full-blown Internet compatible multimedia machines (which may be small, but no compromise on feature set).
Corrections (Score:3)
- The code morphing software WILL NOT be open sourced. It doesn't have to be it's not part of the linux kernel. The code morphing software sits below the kernel translating the x86 instructions into vliw.
-They will release the "Mobile linux" source code but it looks like all that is is a low memory optimised version of linux with power management and an onscreen keyboard application.
Nothing earth shaking there.
But hell, I still want a linux webpad.....
Re:no release of the vliw instruction set? (Score:5)
Linus said that they explicitly decided against doing a native version of Linux for the Crusoe. The whole idea of Crusoe is to keep you from having to recompile while still letting you take advantage of advances in the underlying CPU architecture. Nobody should want a native Crusoe application, because when a new Crusoe comes out with different instructions or whatever, you'll have to recompile. As much as I hate the phrase, this is really a paradigm shift in processor and OS technology.
The lack of a SPARC or Alpha or PPC morphing layer is probably more a pragmatic decision on Transmeta's part. They can't do it all (right away). They didn't rule out a morphing implementation for PPC, Sparc, etc., but they get the most bang for their buck from doing the x86 first.
Crusoe as hard Java VM (Score:5)
A question: because of the Crusoe code morphing technology does this mean that we could program it to translate Java byte code into the Crusoe VLIW instruction set and get a hardware speed JVM? That would be sweet...
Hotnutz.com [hotnutz.com]
Some interesting similarities to MAJC (Score:5)
Been in development for some time, but secretly. (Didn't hear a word from Sun until it was practically complete)
Has the idea of trying to remove backwards compatability hardware problems and issues. (Crusoe with code morphing, MAJC with Java). This makes it much easier to really optimise for each generation.
VLIW type design. Sounds like Crusoe is fixed 128bit - like most designs. MAJC is variable - 32-128.
low power embedded markets. However Sun is more "embedded" than low power (MAJC 5200 is 15W @ 500MHz), but Sun are going for some pretty damn serious performance - eats mutliple MPEG2 streams for breakfast, 100 voice of IP channels at once, or 50-90M triangles/sec for 3D lighting/transform etc - the PlayStation 2 "Emotion Engine" is a similar product (in terms of performance, power, cost) but is rather more conventional.
Both using IBM fab. Both 0.22 initially, and 0.18 later. (Sun are using copper interconnects, I guess Crusoe is too)
The point about doing benchmarks for the Crusoe discussed in the annoucement is quite apt too - with Java HotSpot, the longer you run it for, the faster it gets. Normally, you use a real application for minutes or hours, but most current benchmarks don't run that long, so isn't quite so "fair".
However, Crusoe beat MAJC to being fabbed and sampled. (MAJC should have "taped out" by now, though no official annoucement yet)
Different markets (MAJC doesn't execute x86 for one, but maybe they could add it later...), though there is some overlap - I think both are going to be very interesting to watch. Both bring some interesting new ideas and applications of things.
Some architectural differences: Crusoe could do just about any instruction set "directly" through code morphing - you'd just have to code it. However, don't expect them to do many as it would be a huge amount of work for each instruction set. They can also do more than one at a time. Though MAJC is not a Java bytecode executor (and you could port Linux to it as easily as a typical RISC CPU) it only does it's instruction set. They hope to use Java to make things more "portable", which is a lot harder than the code morphing techinique which is basically transparant. Not much details has been given about the Crusoe engine, so it's hard to compare, but it doesn't yet seem like it has hardware/vertical threading support, or chip level multiprocessing support (more than one CPU core on one chip), for example.
MAJC does have this one thing which similar in terms of complexity and mixing hardware/software though. When running a JVM, you can use a mode called STM (Space Time Computing) which uses more than one CPU to speed up a single threaded Java app (using some interesting thread speculation techniques), which like the Crusoe code morphing engine, is transpart - you don't need to compi
Slashdot mentioned on Transmeta site? (Score:3)
http://www.transmeta.com/mobile/ [transmeta.com]
Looks like someone at Transmeta likes Slashdot, too.
Re:Hrmm... (Score:5)
Will this chip have the same hard time to enter the market?
Probably not. The Athlon is a fine CPU, but it's advantages over PIII are not huge (reletivly speaking).
Crusoe on the other hand isn't that fast (but really, 500Mhz equiv. isn't all that slow either), but it's power consumption is 1/35 that of PIII. That translates DIRECTLY into battery life which has been the bane of laptops from the beginning. Add in to that that a fan isn't needed and you really have something. The lack of a fan is more significant than it seems. Lack of fan means lack of vent holes (with good heatsink technique) which means a sealed case that can tolerate wet conditions MUCH better than a laptop with a fan.
It opens the door to a new class of handheld device. The PalmVII is great (I use one myself), but compared to the Crusoe, it's CPU is absolutely anemic. So in it's niche (tiny laptops and handhelds), it really is tremendously better than the competition.
What's wrong with Transmeta (Score:5)
Power consumption of the chip is lower, but power consumption of the chip is only 20-30% of a notebook, limiting the value of this "revolution."
Further power reductions require either A) giving up a hard disk (aka Linux in ROMs) or B) integrating more than just the CPU and chipset (what about 2D/3D just for starters, not to mention sound, fast ethernet, modem, wireless etc.; note that some of these require analog circuitry not just digital and pinouts start getting complicated)
Sure, Intel's SpeedStep power circuitry is less dynamic, more of a step-function static approach to power management. But is it good enough? If not, will the next generation of their technology in 2-3 years be good enough? Not much of a market window here, in the big scheme of things. Remember, Intel only loses when CPU power is an issue; it can pursue the same no-hard-disk and system-on-a-chip approaches as Transmeta. No patents there.
In terms of integrating 3D, Intel has a huge lead over Transmeta in terms of patent licensing and technology development.
So what about Transmeta in the embedded space, a la cell-phones? This appears to be a backup strategy not articulated yet for one simple reason: the TM processors are still less power-efficient than, say, StrongARM.
Did I mention the difficulties Transmeta would have keeping up with Intel's clock rates and performance? There's not a clear win here today, and this is only going to get worse before it gets better. It's relatively easy to release one innovative product that hits the market sweet spot once; it takes a totally different set of skills to keep up development of an ongoing stream of products that is always competitive with what's in the market. You can see this in the 3D space over the last four years, and AMD also illustrates the ups and downs of playing challenger.
Wireless internet is cool, but I find it hard to be optimistic about the per-month pricing over the next 3 years at reasonable bandwidth rates attracting serious (5+ million) consumers. Guys putting up towers and satellites are the bottleneck here, as is the degree of competition.
;-)
This is all very innovative, and perhaps Transmeta OEMs will sell a few million units of handheld notebook/palmtops, with Transmeta gaining reasonable market share over the short term, IPO'ing to incredible hype, and three years from now realizing that well, they don't have the market position needed to really compete when Intel puts the squeeze on. Their technology value-add that I've seen is too slim that it can't be embraced and extended by some means. I see enough value add for them to survive, to live well and cash in on some sweet stock options, but I don't see them becoming a big or significant player 5-10 years out. Long term, well after the IPO and honeymoon period are over, they only make sense combined with someone like AMD with a much broader product line and established consumer reputation.
How's that for thought provoking?
--LP
Of Hype and Performance (Score:4)
I'm wondering if I watched the same presentation as the rest of the posters here... Deitzel and co. effectively skirted the performance/Mhz question, which says to me that they don't have much to brag about in the performance area, otherwise- They would've bragged about performance/Mhz.
I could've sworn I was watching an Microsoft/Apple/Intel love-in/press-conference at times. A quote of note: "Crusoe will be a low power internet platform for the future". What the fsck does that mean? There was lots of 'marchitecure', but little in the way of hard performance numbers.
Looks like Transmeta's smartest move was to hire Linus, 'cause the whole of Slashdot is believing the (and feeding) the hype without knowing all the facts.
There's an interesting double-standard on slashdot... Announced and unshipping products that are !linux are vaporware, yet announced and unshipping products that Linus smiles on are "the next big thing" and "A new paradigm in computing".
And they say Mac advocates are fanatics...
-t
Transmeta Reads /. (Score:3)
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Crusoe is heavily biased towards x86 (Score:3)
Other than having execution hardware for logical, arithmetic, shift, and floating point instructions, as in conventional processors, the Crusoe Processor has very distinctive features from traditional x86 designs. To ease the translation process from x86 to the core VLIW instruction set, the hardware generates the same condition codes as conven-tional x86 processors and operates on the same 80-bit floating point numbers. Also, the Translation Look-aside Buffer (TLB) has the same protection bits and address mapping as x86 processors. The software component of this solution is used to emulate all other features of the x86 architecture.
So all the people that were thinking about 128-bit floats are SOL. I think that emulating non-x86 architectures on Crusoe is going to be possible, but noticeably harder and slower than x86.
Kaa
Crusoe is heavily biased towards x86 (Score:5)
Other than having execution hardware for logical, arithmetic, shift, and floating point instructions, as in conventional processors, the Crusoe Processor has very distinctive features from traditional x86 designs. To ease the translation process from x86 to the core VLIW instruction set, the hardware generates the same condition codes as conven-tional x86 processors and operates on the same 80-bit floating point numbers. Also, the Translation Look-aside Buffer (TLB) has the same protection bits and address mapping as x86 processors. The software component of this solution is used to emulate all other features of the x86 architecture.
So all the people that were thinking about 128-bit floats are SOL. I think that emulating non-x86 architectures on Crusoe is going to be possible, but noticeably harder and slower than x86.
Kaa
Re:transmeta.com /.'d (Score:3)
Re:Emulators (Score:3)
Hmm, this raises an interesting thought: Would Crusoe eventually replace other architectures? Since it can simply run different Code Morphing software to emulate every existing architecture out there, why can't we code directly for Crusoe's native instruction set?? We don't need other architectures at all...
I understand that one advantage of *not* coding directly in the native instruction set is that Transmeta can totally revamp the instruction set and simply release a new Code Morphing software... but still, while a particular release lasts, why not take advantage of it?
Taking this further, Transmeta *could* release a "static" external instruction set that the Code Morphing software translates into whatever the current native set is. Then we don't need other architectures *at all*. All we need is to use this static external instruction set. We don't even have to worry about being compatible with future releases of Transmeta, since the Code Morphing software takes care of that.
To conclude... WoW! I think Transmeta could be hitting something real big here... congrats!
Re:Relative performance? (Score:5)
During the Q&A session someone asked how the performance on the crusoe compared with that of the P!!!. After a bunch of normal disclaimers about different system configs, beta silicon, and beta x86 decode software they finally equated a TM5400 @ 667Mhz to a p!!! @ 500. Not bad for code morphing in a beta state plus all the potential power savings.
Under 1 watt -- that's bogus (Score:3)
for the TM5400: (the future one)
while playing a DVD: 1.8 W
while playing a MP3: 1.0 W
for the TM3120: (the current one)
while playing a DVD: 2.9 W
while playing a MP3: 1.4 W
Kaa
Tech detail highlights (from the white paper) (Score:3)
Code Morphing software will "typically reside in standard Flash ROMs on the motherboard". This implies it could be in RAM, and potentially dynamically reconfigurable or switchable, on a suitable designed motherboard. (Elsewhere the paper implies that this ROM software is or can be copied to RAM at boot up for faster execution.)
The VLIW engine has "two integer units, an [FPU], a memory (load/store) unit, and a branch unit". These can operate in parallel.
All VLIW code, both translated x86 (or whatever) code and Code Morphing code, live in a separate memory space invisible to x86 code. The size of this memory space can be set at boot time or the OS can make the size adjustable. This last implies that the OS can somehow see this memory, so it's either not totally invisible to x86 code or the OS has some VLIW code hooks.
"The Code Morphing software includes in its arsenal a wide choice of execution modes for x86 code, ranging from interpretation [...] through translation using simple-minded code generation, all the way to highly optimized code [...] A sophisticated set of heuristics helps choose among these execution modes based on dynamic feedback information gathered during actual execution of the code." This sounds a lot like Sun's "HotSpot" technology for Java VMs. Either way it sounds cool..
"the translator adds code whose sole purpose is to collect information such as block execution frequencies, or branch history."
There's hardware support to help the code morphing, ie support for exceptions, speculation, optimization of memory and for self-modifying code. All x86 registers are shadowed, there's a working and a shadow copy. As blocks of x86 code get translated, that page's entry in the Crusoe MMU (for the translation cache) is marked as "translated" so that it doesn't get translated again. A write (by x86 code, indicating self-modifying code) into that block causes that bit to be cleared.
The Crusoe processor voltage and clock (at least on the 5400) are accessible to the Code Morphing software, which can adjust them on the fly to optimize power/performance for the running app.
Backwards compatibility isn't the important part. (Score:5)
The implication that they consider the low level stuff part of this their business, and, as you suggest, the "cash cow." It is part of their "competitive advantage" to be able to do that which nobody else can, which is to customize the processors in this way.
ON THE OTHER HAND. Not giving out the underlying instruction set means that they never have to apologize if they change the instruction set. They claimed that there were different instruction sets for the 3120 and 5400 models; if that be the case, it would be no surprise at all if later models are different again. If people are interactive via "middleware" instruction sets, then all Transmeta need do is to make sure that the microcode continues to support the "middleware," whether that be IA-32 or JVM.
Vision for the Future.
There is a really cool thing that this offers... Wouldn't it be a neat idea if Linus were to create what we might call Linus' Favorite Instruction Set, with all the features that he wishes there were to make Linux as fast and robust as possible?
Alternatively, the Lisp Machine people might find it a slick idea if Transmeta provided microcode to provide a Lisp-oriented instruction set that (notably) provides a really tightly microcoded set of garbage collector instructions. That would let them both benefit from MHz enhancements as well as from generational enhancements, perhaps simultaneously having some IA-32 emulation going on so that they have a virtual machine alongside providing PC compatibility services...
Re:What's wrong with Transmeta (Score:3)
This isn't a bad critique, but to me it looks like the improvements Transmeta has acheived in power consumption could really enable smart, powerful, application machines that are worth something. PC's that now cost $1000 or less can be replaced with tablets that have browsers and a few office apps on top of Linux. Let's face it, that would meet the computing needs of 90% of the populace, and having no fans makes them much more home and SOHO friendly. Storage is the only remaining obstacle to having nice little machines that do all this, and there is hope on that front as well (I seem to remember reading about a technology for 2300GB, solid state, deck-of-cards-sized, $200 drives in the next two years - just imagine your portable MP3 collection!). This might be a better way for Linux to bury windows - start with WinCE and work from there.
Re:Multiple OS use on the Crusoe (Score:3)
The Crusoe does nothing for making the switch from Windows to Linux easier. Nada. Same for BSD, Be, etc... It does just as much as did the Athlon, except Crusoes effectively a version 1.0 product coming from a brand new company, as opposed to Athlong which is a much more matured product that merges the best of two already mature companies products.
Java shouldn't even be included in that discussion, unless a JVM is ported to run directly on top of Crusoe.
And of course any journalist worth their salt HAS to ask about IPO's. With Amazon's, Ebays, Redhats, VA Linuxs, etc, it's the simple truth that Transmeta will in all likely hood go public (they talked about who supplied their first round and second round of financing. The next logical step is to go public). That, plus the hype they've drawn to them selves, and the market they've painted for their processor.
Re:Emulators (Score:5)
Remember, their chips' have no out of order execution units; they do this all in software. Instead of having lots of silicon to do agressive instruction scheduling optimizations on each instruction every time round a loop you re-execute the same old instruction again, their "code morphing" layer gets to lazily decide when to put in more effort into instruction recoding as it becomes obvious that a section of code need it.
And the beauty of it all is that these instruction translations are saved in memory - you get to preserve a lot more state, you get to save instruction sheduling decisions, whereas silicon has to always repeatedly make those decisions over and over again as it reexecutes the same instruction.
Re:x86 compatible? (Score:5)
Unlike the PIII or K7, which have special microhardware to translate 32-bit x86 ISA to the 32-bit RISC internal cores, the Crusoe uses a hybrid hardware/software module (patenteded, et all) that translates the 32-bit x86 ISA into 128-bit VLIW core. The fact it's in software allows them to apply RAD techniques to their translation code, which is a big win, allows them to reconfigure the hardware based on the programs running for optimal power consumption, and allows software overclocking
"Is there any reason to believe that applications written natively for this would be able to avoid the code-morphing layer and run even faster?"
Nope. Unlike the K7 and PIII, the translation is important to the process. For performance, they likely have the translator units running at a fast enough speed that the VLIW core is kept as full as if it didn't have a translator unit. And without the translator unit, you'd have to spend a few more man years designing a new BIOS, chipset, etc, that understand VLIW, as well as a new instruction fetching unit. It's easier to support the x86 ISA (which everyone supports), and stick with the design they have now. Besides, as they have pointed out, the purpose is to have a reliable low power CPU, not an "oh my god, I came it was so fast!" processor. This is best accomplished with a smart translator that is software reconfigurable around a simple VLIW core.
This doesn't stop the idea of a very high performance VLIW core desktop machine, which is what Intel is lusting after with its Merced. Luckily, the Cursoe seems a lower-level version of the Merced, which should stop any Intel strangehold on the VLIW market. And when AMD extends the x86 ISA with 64-bit instructions, your Cursusoe from the ol' year 2000 will be able to handle it. Flexbile; extensible; cheap -- I like it.
---