Slashdot Mirror
UPDATED: Transmeta's Crusoe Unveiled
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."
I'm wondering about emulator programming.. Linus said something about "emulators on steroids". From the various comments, can anyone tell if the processor instruction can be dynamic, done in user space? ie can I pop open a MacOS/ppc vm and have it get the cpu instructions while I run another host os a-la VMWare?
MSNBC: http://www.msnbc.com/news/358517.asp
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.
I just wonder how successful this chip is going to be. I mean nobody is denying the fact that Athlon is far superior to the P3, but in all the adds from Toronto computer magazines, you barely see any systems running them.
Will this chip have the same hard time to enter the market?
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.
Chris Tembreull
"My karma just ran over your dogma."
Intel must be collectively quivering in their proverbial shoes after this conference. After watching and listening, I am wondering, are we seeing the Next Great Innovation(tm) in processors? The paradigm that Transmeta has created with Crusoe is so different, I have the feeling I was watching a new chapter of the history of computing being written before my very eyes.
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 Crusoe information is all very incorrect. I can't believe Slashdot was so badly misled. If you go here (http://www.nitrozac.com), you'll see what tech-savvy readers have known for months: Transmeta is building a multi-story abacus. In fact, I thought it was unveiled a month or two ago, but mysteriously disappeared.
they said that they may not release the native vliw instruction set because they want to keep the freedom to change it in the future and don't want to worry about breaking compatilibility.
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?
Id say it means small kernel and system overhead (efficient use of memory, and small executables) as well as efficient use of other system resources.
So in that sense it would be similar to the design of the PalmOS, i wont even mention WinCE as its such a pile of crap...
Cant wait to see the code released so we can know exactly wot was changed / optimized / added.
It seems hard to believe that they'll get twice as much battery life as existing laptops. I'm no expert, but I'd say that the screen, HDD, DVD drive, etc waste much more energy than the microprocessor. Anybody that knows this stuff cares to give his opinion?
>My chip (Celeron) is running right now at 34 F
Wow! An exothermic chip?
:)
Room temperature is about 70 F, and I BELIEVE that 48 C -> ~118 F. That qualifies as 'slighly warm' in silicon temperatures. A P3, on the other hand, would give you a pretty nasty burn, if you touched it with your bare hand.
jf
About the size of a 12" LCD panel (thickness, too). I couldn't figure out which window manager it had on, the image was quite bad.
Yes, it sounds like a kick ass product... I listened to the conference until my connection konked out around 1:05. But I was still hoping for more.
According to all the rumors I'd heard, this chip would be able to load many different instruction sets (PowerPC, SPARC, etc...) and always pretty much be running in a native mode.
Of all the complaints I've heard about x86 processors across the years, the one that sticks out the most is that they're a pain to develop for. This new chip does nothing to alleviate that.
In a way, transmeta's become like Be. Be originally set out to take over the world (or at least, the Mac OS market place), moved onto x86 and realized that can't beat Microsoft out of the market place, so they might as well try to co-habitate as well as they can. Transmeta has a really cool product, but has also realized that they can't really push intel out of the market place, so they might as well just aim for intel compatibility...
Too bad it sounds like they expect nothing to be written in Crusoe's native language... There must be some speed improvement that could be gained, if say, Crusoe's achieved 40% market share in the notebook market, that would make it worthwhile for developers to create Crusoe ports.
The web pad was about 8.5 by 11, and had no keyboard. it had a one inch frame, and the rest was a touchscreen. it looked about one inch thick. The model was using some sort of stylus on the screen, and it had a drop down virtual keyboard. Otherwise, it looked like a busy KDE or Gnome environment. They were really showing off the web-browsing more than the environment. I never heard any details about how the device connected to the net either.
It sounds to me like the real fun is in speculating on what the Crusoe COULD do, or make possible, once various CPU instruction sets are implemented.
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.
Transmeta could make a bundle by selling cheap Crusoe(tm) development systems built on a PCI card. You know we would all get one if they cost
Or, I suppose, they could just create a Crusoe(tm) system emulator program that ran on x86 architectures that would then emulate x86 architectures :-) Of course someone would immediately try to run the emulator in the emulator in the emulator in the...
How come they still haven't updated their web site? I was expecting some change at least...
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
another interesting point...
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)
In all the reports I've seen so far the 5400 has been described as a "windows chip", and nothing is said about Linux. Naturally I assume that anything that can run Windows can run Linux too.
Life's a bitch but somebody's gotta do it.
In the Q&A he asked, "Since Linus helped to develop the chip, it is Linux-based. Will it also run Windows?"
This, after an hour of presentations, including running several demos of Windows apps (including Quake), references to the fact that they have tested 30 OSs on it, and a myriad of references to Windows specifically.
The "mainstream" press is missing the point. I'll bet they label this an Intel-clone from Linus and the public will yawn.
I have a "Zero Policy" tolerance.
*/
I appologize if this has already been addressed. Alas, my connection to slashdot is poor and it took forever to bring up the reply page.
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!)
The cool thing about it is that it uses software only to translate x86-instructions to it's native instructionset. It then stores this translations in a translationcache to avoid retranslating everything over and over. This is the code-morphing you are talking about.
But the translationprocess doesn't simply convert x86 to native instructions. It also optimizes the instructions. This can sometimes reduce de number of instructions by 50%!
As I understand it this means two things:
1) It should be possible for very fast software to use it's native instructionset.
2.) It isn't as easy to addept for other architectures then the x86 as writing a new translationpart into the code-morphing layer, because the whole optimizationroutine has to be rewritten too.
If there is hope, it lies in the trolls.
So now that mobile Linux has been demoed to the world, when is Linus going to release the source? I didn't hear any mention of it during the webcast (although I had to leave part way through). And I guess the other question is, is this a kernel fork in progress, or is it a common kernel with what we've been seeing in development right now?
Hotnutz.com
Linus really didn't have a choice when you think about it. If he'd ever said 'Yes, what I do for Transmeta is Linux-based.' It would not have been very hard to conjecture what he really was doing.
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
Don Negro
Perl 6 will give you the big knob. -- Larry Wall
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).
-- @rjamestaylor on Ello
I'm sorry, 1W descibed as 'incredible' power consumption betrays a serious lack of perspective. The ARM7TDMI consumes 0.6mW per MHz on average (note the 'milli') and these usually run at 66Mhz! That's less than 39mW for a typical processor. 1W means squat until we see the performance figures for this thing. I don't see it making great waves in the mobile device sector unless the power consumption is drastically cut. And what's this about hardware x86 emulation? Have we been tricked by the pre-release chatter? Everyone was talking about this thing being software driven on the emulations side. For now established RISC-based processors don't seem to be challenged.
-Linus got his ass kicked by Dave Taylor (co author of doom and quake) not the CEO. But the quake3 performance was great if they didn't have a 3d graphics card in there. (i.e. is was running in software mode).
- 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.....
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
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
I think I should explain something. What does 128-bit VLIW (Very Long Instruction Word) processor mean? It's not about register size. Neither about data or address buses size. It's instruction word size. The processor itself is probably 32-bit since it's supposed to emulate IA-32, but it could be 64-bit. some numbers: 8088: address bus size:20 data bus size:8 register size:16 instruction word: min=8 max=64 ??? instructions / cycle =~ 0.1 i486: address bus size:32 data bus size:32 register size:32 instruction word: min=8 max=120 instructions / cycle =~ 0.7 pentium: address bus size:32 data bus size:64 register size:32 instruction word: min=8 max=120 instructions / cycle =~ 1.3 K7: address bus size:32 data bus size:64 register size:32 instruction word: min=8 max=120 instructions / cycle =~ 4 crusoe: address bus size:? 32..36 ??? data bus size:? 64 ??? register size:? 32 ??? instruction word: 128 ! instructions / cycle = 3..10 (integer value !)
Linus said in the webcast that Transmeta made a mini Linux distribution for its licensees. However, if the licensees could not publish that GPLed software without violating their NDAs with Transmeta, then the GPL forbids Transmeta from distributing that Linux. It doesn't say anything about whether the licensee wished to publish or disclose, nor does it say that the NDA must be amended, it says "if" and "refrain". Hey, I'm not gonna call 'em on it, but what do you all think? :)
Quoting from the GPL (and careful, don't confuse the example they give with the principle):
Well, I was going to buy a Handspring Visor (running PalmOS) but I guess I'm waiting for one of the Crusoe processor based systems now. :)
Handheld Quake. Three words: Cool as hell.
Judging by the following URL -
http://www.transmeta.com/mobile/
Looks like someone at Transmeta likes Slashdot, too.
First, let me say that the chip looks mighty cool. However, I was very disappointed in their not releasing industry standard benchmarks.
While I understand their wanting to show their big power advantage, trying to mix two totally different measurements such as power consumption and performance into a single rating is the height of marketing bulls**t. But OK, if they want to, that's fine.
But not at the exclusion of real performance benchmarks. Show me the components that went into the bulls**tmarks or whatever your new benchmark is.
At one point during the Q&A, someone made this point, and the engineer dude (can't remember his name) said that a 667mhz Crusoe performs like a 500mhz P/III. *cough* I'll believe that a software-based emulator can get 75% of native hardware performance when I see real benchmarks. Until then, all this handwaving makes me very, very suspicious.
All this having been said, the screens flashed by pretty quickly, so clearly it's not a dog. But Transmeta: if the performance is good DON'T HIDE THE NUMBERS.
---
113 C is fairly trivial. Yes, water will boil, but copper and plastic melt at higher temps.
Yeah, intel has ALWAYS run hot. The whole damn architecture does. That's why PCs usually die of poor ventilation (next likely cause of death is cheapo power supplies).
Will this take off? Is it Better(tm)?
Well, the StrongARM chip ROCKS. You can power a nice little home computer with a wall wart ala TRS-80's and C64s. But at 250MIPS.
Will they win?
No. Not unless there are things running on them that are compelling to the customer. Users don't care about Excel, or Netscape or whatnot. They want to be able to do things with their computers. If they are taught that Excel is what they need to do these things, they will use that. My Mom wants to write up a report. Doesn't matter what it is as long as it does what she needs and does it without showing itself too much.
Star Office and Applix are close but not there yet, but they show themselves to much. People want to type things in and get them out looking pretty.
The Palm beats Wince and Psion because (except for learning graffiti) it gets out of the way and lets people do things. Psion goes a bit further by punishing developers by needing to profit from their developments kits (hint: make it easy to write software for your hardware and more people will use it and you'll sell more hardware).
If the Crusoe processor is underneath any of these, fine. If my phone runs (RT)Linux, fine. But if I can't make a call or get stuff done, then it's getting tossed into the river with my Wince device.
Summary
Heat? Not your issue. Battery life it your issue.
You have an Intel chip with snow forming on it? Give me some of what you're smoking.
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
There's another chip that can run any x86 OS: it's called the Pentium.
Just because this chip is good at emulating other instruction sets doesn't mean that you can magically run multiple OSes at the same time without rebooting. That's still an incredibly hard problem.
They did say that the chip itself can run multiple instruction sets without resetting between them, but that's still a far cry from saying they've solved the problem of scheduling multiple OSes: since every OS has its own scheduler, you'd need a meta-OS with a meta-scheduler. Not to mention the problems of locking hardware access, etc.
Being one of a few (if not the only) negative poster, I'm likely to get branded (and moderated) as a troll/flamebaiter, but please hear me out...
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
Just judging from the screenshot in the lower right. That is *if* you can get through to the site.
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
And here is an example (quote from the datasheet for the 400MHz processor):
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
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
And here is an example (quote from the datasheet for the 400MHz processor):
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
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
And a mirror of the mirror is mirrored at http://www.attaway.org/~ dattaway/www.printf.net/transmeta/ as well as the irc transcripts. Enjoy!
instructions in software rather than built into the hardware? isn't that basically what a winmodem does? ;-)
More or less, but it's not the same! :-)
A winmodem takes what the chips on the modem should be doing and dumps the work off on the CPU instead. Normal modems also run in software, it's just that the software (firmware) runs on the modem hardware.
Again, some quotes from the datasheets for the processors:
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
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
- The strongARM only requires about 400 milliwatts vs. the crusoe's 1 watt.
- The crusoe has compatibility with existing software (not just x86) via the code morphing whereas the strongARM is a platform unto itself.
- The crusoe might have a faster clock cycle, but are the extra megahertz used up by the CodeMorphing?
Whatever the verdict, when coupled by emergent display technologies (OLED and SSD), it looks like the future of ultra compacts is all bright and shiny right now.I'm also wondering what the overclocking potential of such a low heat dissipating CPU must be :-)! Imgine one of these babies in a cryotech tower (this is more or less a joke - laugh, damn it!).
-- kwashiorkor --
Pure speculation gets you nowhere.
-- kwashiorkor --
Leaps in Logic
should not be confused with
Jumping to Conclusions.
It's called mac-on-linux and ios under GPL. See www.ibrium.se/linux for details. You'll need a copy of MacOS and a PowerPC linux system. (just like vmware needs windows and an x86). Of course, on this new toy, cpu emulation of the G3 might be practical if someone will write it...
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Some highlights from the technology whitepaper on the Transmeta website. It should answer some of the FAQ's raised here so far. (My comments/observations in italics).
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.
-- Alastair
TM312 0 Data Sheet
/.'d than Transmeta is right now! LOL
TM540 0 Data Sheet
FAQ
Looks like they beefed up their web backend in the last few minutes, the slashdot effect that was going on has disapeared for me. Slashdot seems to be more
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...
If you're not part of the solution, you're part of the precipitate.
You and me both!
Hidden away in the Press section (along w/ some unimpressive pics of the chip) is the Transmeta FAQ:
http://www2adm.transmeta.com/press/faq. html
Interesting stuff.
No offense to you or anything, but how in the world was that "interesting"?
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.
The thing that disturbs me is that we have benefitted as consumers from the competition between intel, AMD and others. If what transmeta has done in fact turns out to be a significantly better design approach, they may never see any real competition.
Intel has to publish it's instruction sets to get people to write software for the CPUs. Nothing legally prevents other companies from designing CPUs that offer the same instructions. Thats why AMD and others are in business.
During the announcement, transmeta indicated that it has been granted (or was it sought?) numerous PATENTS, not just copyrights, on concepts related to software defined instruction sets. If they are upheld, would that not keep any other company from designing a hardware / software combination that does a similar thing from competing with them, even if the hardware and software were designed from scratch?
If someone reverse engineers a crusoe cpu and builds one that is hardware compatible, and transmeta refuses to sell the software component without the accompanying cpu, isn't that like the old apple machines who never licensed the bios so there could never be a (legal) market for clones?
Yes, this post is another thinly veiled rant against intellectual property rights law, as it impedes growth and competition in many industries.
"Monopolies cannot come into existence without the assistance of government." - Ayn Rand
I don't want the government to break up monopolies when they become large and vicous, I want it to stop creating them.
"It's the code-morphing that makes it compatible right? Or is there some deeper compatibility at the hardware level?"
:-) This is the reprogrammible CPU we've all secretly lusted after... And because its core is VLIW, I hope we can leave behind those "[R|C]ISC is better" flamewars (which were really pathetic). The VLIW core is also very much simpler in design and cleaner (asthetically speaking) than either CISC or RISC. This is why the chip can be so cheap for the speeds they get, why it's so cool (pun), and why it uses so little power (more so inconjuntion with their translator).
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.
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
They're not trying to make the "newest fastest :>). Sure, a PIII 500 isn't the fastest
most-expensivest" processor - they're going to
viable portable devices (1.5-2 hours is not
viable
thing out there anymore, but it's not bad.
A PIII 500 equivalent w/ 6-8 hours of battery
life is a truly viable portable. Admittedly
the other components may suck down a lot of the
power, but hopefully having this chip available
will spur IBM, WD, or some other storage solution
company to create a large capacity, low power
comsumption solution that is also affordable.
The IBM Microdrive is a relative low capacity
(340 meg?), but it's small with low power
consumption.
Basically, it will depend on your needs (as usual), but what I'm looking for in a notebook
is compatibility w/ my existing apps (not a
rewrite of them, like the WinCE version of Word),
the ability to do basic tasks (word processing,
some game-playing, e-mail, etc) and BATTERY
LIFE - something I can lug around all day
and use, not something that becomes dead weight
after 1-2 hours of use.
ObTagLine: The more you run over the 'possum, the flatter it gets.
Emulating CISC based hardware is vastly easier than achieving acceptable performance emulating RISC based hardware. With CISC based hardware, each instruction does a lot, and might take several clock ticks to execute. The Transmeta emulator can come along and translate the instruction into equivalent Crusoe instructions, and achieve roughly comparable performance. This is why PC emulators can be run on PowerPC hardware, and why the MacOS's 68k CISC emulator was so successful for running old applications on PowerPC based Macintosh's.
RISC emulation is vastly different. Each instruction doesn't do a whole lot, but runs extremely fast. So, basically, to emulate a RISC processor, you have to translate each instruction into one or more Curose instructions that don't benefit from RISC hardware's pipelining and other efficiencies. You're going to end up with a vastly slower PC.
Also, this chip will not be able to emulate multimedia enhancements like 3DNow or the G4's velocity engine as fast as the native version. These chips are optimized to run the special instructions in a highly efficient and parallel manner. The multimedia enhancements in hardware basically utilize almost all the hardware technology that Transmeta has in their chip, and tehy don't have the overhead of translating intructions before being able to execute them. The Transmeta chip's software layer simply won't do as good a job as dedicated vector processing units.
Please remember that 700mhz doesn't mean shit. You need to know how fast the processor actually runs x86 software, not how fast it runs the Crusoe transcoding software. Its the same with all emulators. Would you rush out and buy a Macintosh with a hypothetical G4 chip running at 1GHZ that only emulated x86 software? Of course not! You'd know that a x86 native processor running at 700mhz would probably be faster.
Sig goes here
Please ignore the complete assholes who are flaming you for an obvious typo. Anyone with a three-digit IQ knows you meant 34C.
A translation cache is still better then nothing. If you think of a cache like a window on a portion of the code, and then you can imagine that only a small portion of the code (less than 1K) would be kept in the cache. The TM3120 has 108KB of cache, but the TM5400 has 400KB cache, which sounds like a good amount.
Cache works because it exploits the locality principle. The locality principle says that the 2nd memory reference that comes in sequence after the 1st memory reference will most likely be close to the 1st reference. This means that addresses are grouped in clusters, instead of being in stored in random locations.
Cache memory is many times faster then main memory, therefore the CPU can access the cache memory much faster. If we know that memory references are grouped in clusters, then it makes sense to copy a whole cluster of memory into the cache all at one go. The CPU accesses the cache at one address at a time, and because of the locality principle, the CPU will always get more hits then misses.
If the cache ever runs out of space, the least used cluster is evicted from the cache - this guarantees that the most used clusters are always kept in cache memory the longest.
I also believe that the locality principle can be applied even better to code, since code tends to occur more naturally in groups of clusters (eg functions) and better predictions can be made on how frequently the clusters will be needed (eg inner loops)
I do not think the Crusoe chips will have any problems with cache..
And obviously neither are you, because Linus only owns the copyright on what he wrote. He didn't write the OS himself. Other people have copyright on their contributions, and licensing of their own. Just how do you think he would retroactively be able to change *someone else's* licence?
Open Source. Closed Minds. We are Slashdot.
So, since we could get updates to the CPU off the web as they said in the presentation, what's stopping people from creating a program that turns my Crusoe chip into junk a.k.a. a Crusoe virus.
How do I fix a chip that doesn't have any instructions in it?
" Will it run Quake????? "
Ahh, the penultimate question of the ages -- will it run Quake.
Itchy reply finger, meet my itchy trigger finger..
Even with the site and 'cast asside, this is a laptop processor. Nothing says Quake can't run on a laptop, unless the laptop is an iBook or something. But the Cursoe proc emulates x86 ISA... So the answer is a simple 0x44 0x75 0x68..
Thanks for your time.
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I took a compiler class in college, but only remember enough to be curioius, and am hoping someone who knows what they're talking about could answer.
Compilers do a lot of compile-time reasoning to try to predict what happens at run time, optimizing both register use and instuction order. However, this is not done solely based on the ISA- there are significant assumptions about how the processor actually executes instructions.
Crusoe, in optimizing execution, has the benefit of *knowing* what's happening at run time, as opposed to a normal compiler that has to guess about it at compile time. Also, because the x86 ISA is implemented in software, they could do all sorts of crazy stuff beyond instruction reordering. For example, if the compiler guessed wrong about what set of values to keep in the registers, the code morphing software might be able map hardware registers in Crusoe to values that were being sent to memory in the original code.
Which is all well and good. But given that there now are two astonishingly different execution models for x86 code, what are compiler writers supposed to do? Is the amount of information that a run-time optimizer has so much better than a compile-time optimizer that the compiler guys should just give up? Or do the constraints on the complexity of run-time algorithms (they've got to be *fast*) mean that compiler optimization is still worthwhile? If so, how will compiler authors cope with the potentially vast differences in optimizing for Intel vs Crusoe? Will we be seeing a Crusoe-opimization flag in gcc?
More questions than answers...
48C? Get a new water heater. If it's the kind that stores the warm water, not only is it not really hot enough for washing up etc, but also, it's a breeding place for all kinds of germs...
average water heater is 60-80C.
The point is, if you compile C code for the VLIW, it will likely run slower than the same code compiled for the x86 architecture and then run through the code morphing software.
The reason for this is simple: read their tech whitepaper. In it, they talk about memory protecting for out-of-order loads and stores.
If you have C code like
b=a[d]; *c=5; h=a[d];
then this code will run slower unless you can do the out-of-order check and run-time recompilation: if you compile it yourself for the 128-bit VLIW, you lose: your C compiler is NOT ALLOWED to perform the same optimizations since you could get incorrect results.
The really new innovation by Transmeta is those small bits of simple hardware that allow them to trap violations of optimization assumptions, not the 128-bit VLIW part: the latter could have been done by anyone at any time.
Well, stopping the rant now and beginning to wonder when I can get my hands on one
With the cheap and non-heating parts, you could build a pretty big beowulf or SMP machine inside one tower case --- now that would be something.
This is much along the lines of what we discussed here in a post from last September. See the Chips that change on the fly thread (starting at post #44) from September 23rd.
Too bad they didn't give out prizes for guessing right. :-)
"I thought they would focus that as a "feature", not a mainstay of their product."
It is a feature. Did you not digest any of the info about the translation unit? It can emulate any ISA you care to specify.
"I am disappointed to see the archaic and outdated x86 architecture perpetuated by what I once thought to be a high-tech company on the bleeding edge"
I am disapointed you wasted time whinning about an ISA with a firm foothold in the world. Given an OS like Linux, you can swap processors as much as you want (ie: it's a commodity), but not everyone is using Linux.. In fact, of the 400 million (or so) Windows installations out there, I'm willing to bet a fair number of them are running on a processor that runs the x86 ISA at some point. A lot of other OSes also can run on it, like BeOS, Linux, *BSD, etc. If you don't like that fact, go buy a G4 or an Alpha, and support alternative processors. Whinning about it on Slashdot is like showing up at your local video store, and whinning about how they don't stock Beta, and why VHS is so much worse than Beta..
"AXP, sparc or even MIPS has a better architecture than the x86."
*Yawn*..
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
It isn't that I don't understand their argument, I just don't accept it. It's the same old closed-source, proprietary argument.
Here's the software analogy of your argument.
"We don't give out the instruction set because we don't want to give the information needed for random people to write compilers. They would end up with things like "Linux, only for the Sparc." It makes sense for them to only let people write software for interpreted languages like BASIC, or any other future languages that we decide to allow people to write in."
What they are really doing is locking people out of the market for interpreters for other architectures. Want a morpher for the IBM 390 instruction set? Transmeta decides whether or not you get it. If it doesn't suit their business plan, you won't get it.
This is the antithesis of the open source philosophy. You can't "scratch your itch" if you're locked in handcuffs.
This is just a cheap, low power x86 clone. All the "cool stuff" is meaningless if it's not available to the interested programmer.
As I said, underwhelming.
- John
Inoshiro wrote:
``You keep using that word. I think that you do not know what it means.''
Penultimate is not just a fancy way of saying ultimate. It means second-to-last.
firstly, two points to think about:
;-).
1. the chip is not only more efficient but also colder, hence you save also the fan (power, noise, moving parts).
2. there is such a thing as enough power. we have passed the stage where you wait for applications - now they wait for you. this will power application machines. I seriously doubt it will power games, graphics, etc' machines.
now for the neat part ("paradigm shift", I guess):
computers have been stuck in two ways till now - one is that the smallest unit is still the pc, and the other is that the possibility of backwards incompatability has kept us stuck with x86-intel-microsoft, er, technology
what we get now is there is another layer - a "transformation layer" between the hardware and the software, allowing improvement in the hardware without losing compatability and also running code from different architectures together. this is a step forward, and a paradigm that have definite advantages that should allow it to survive and compete, despite being slower and (probably) not doing risc well.
the second neat thing (which actually refers to my first "being-stuck" point) - this could possibly realize the niche of smaller-than-pc computers. until now it just didn't work well enough, can we now expect a small notebook/diary/phone/organizer/whatever to be the "common pc" (let's say for every member of the family/business) with fewer, more powerful computers being the centers of local networks and/or doing the real heavy work (and games). well - just think of the possibilities...
this is a new step, all you are saying is that it is possible to not use it well - but just think of what can happen if it is!
the AC $0.02, hope it was worth your time...
You can run quake 3 in software mode under mesa as you say at about 3 frames per second.
But you're missing something here. This is transmeta we're talking about and that was Dave Taylor, the SAME dave taylor that once leaked a document onto usenet ranting about the inferiority of hardware graphics accelerators and that what he really wanted was a generic parallel processing chip that could do arbitary transforms.
(anyone got the link to that usenet posting on deja that dave taylor tried to cancel?)
GEE, a lot like the crusoe chip can do?
Isn't it feasible that they have put hooks into their code morphing software that optimises specially for 3d transforms and mesa/opengl?
Especially in the linux version? Where they have all the source code to linux and mesa?
Hmm, what fancy optimisations could those clever brains come up with.
Maybe those transmeta laptops WON'T need 3d accelerator ships?
And it would completely defeat the purpose of a low power laptop to put a big,hot,power sucking 3d chip in it. So I'm assuming that demo of quake3 they showed WAS running in software mode.
Someone prove me wrong?
Transmeta doesn't really have to participate in the clock speed race (BTW, if you factor price into it, Intel isn't even close right now)... A 700MHz P3 and a 700MHz TM5400 CPU do not perform the same. In a repetitive section of code (which is most of the code being executed in real world applications), the P3 just executes the code over and over re-doing the instruction translation, the scheduling, and all those things. The TM5400 "learns" what the code is doing and optimizes it down to the point where it executes that code at the same speed when stepped down to 400MHz as the P3 700 does running at full speed and full power consumption.
The example they give is a DVD player, by the time the first video frame has loaded the entire DVD-decoding process has been translated, stored in a translation cache (so it is never translated again), and optimized. If it continued running at 700MHz it would be performing like a 1GHz P3, but instead it steps down intelligently. If stepping down would lose frames or slow execution speed, it wouldn't do it... so until code really really needs over 700MHz in real world applications, Intel will not have outpaced Transmeta. Ithink they'll be around for awhile. And I don't expect this to be the only thing they do. They say they're going to be a professional R&D lab, i doubt they're just goin to keep adapting these processors to different things, they'll move on...
These facts eliminate a few of the bad things you pointed out... like what is the point of integrating 3D if all of the 3D instructions are cached and optimized? There wouldn't be much of a speed improvement if any....
Esperandi
I don't want to make a big deal out of it (I said a "technical" violation) but it is not an open source question. It is a question of putting no restrictions on redistibution.
even if it has been done already. That sounds like something a troll would say but it is true, several companies tried this before. I think Crusoe will become popular because it has Linus working on it (free publicity) and it is compatible with current software. Of course mobile users will be all over this but it also has some applications in thin clients and terminals and probably POS terminals. The power consumption and low cost would work to save companies oodle of dollars, not to mention the chips are software upgradable so their useful lifetime is probably 50-75% longer than a regular processor. Does anyone think they might release a code translator for IA-64?
I'm a loner Dottie, a Rebel.
The LCD screens are one of the largest power suckers on palmtops (no moving parts, so no HD). That's why I get 30hours battery life from my greyscale Psion series 5 and those palmtops with backlit colour screens (HP) get 2 hours.
Deleted
The first describes the benchmarking technique, the second describes the results! =) I would have had it up sooner, but either /. is flakey today, or my connection is. Share and enjoy.
c hmarkWhitePaper_1-18-00.pdf) (.pdf, 93 KB)
s oeBenchmarkReport_1-18-00.pdf) (.pdf, 116 KB)
Mobile Platform Benchmarks (http://www.transmeta.com/crusoe/download/pdf/Ben
Transmet a Mobile Benchmark Report (http://www.transmeta.com/crusoe/download/pdf/Cru
Sincerely,
Ryan Taylor
- Company XYZ patents software, they are denounced by the "community" as greedy profiteers
- Transmeta patents software-morphing and they are revolutionary geniuses
- Company XYZ cracks down on trademark use in domains and is demonized by the "community"
- Linus cracks down on the use of "Linux" in domains he doesn't "approve" and he's a God
- Company XYZ produces a closed source OS that gains 95% market share and they are considered the devil by the "community"
- Transmeta produces a closed source emulation software and they are the holy grail
How ironic indeed.
This would be an instruction set chosen to be particularly efficiently translatable into the Crusoe native instructions, but would remain constant as the processor changed.
Why can they do this when others can't? Because they can have x86 compatibility at the same time, and cheaply. The system could simultaneously run both formats, just by having multiple translators.
And they could do other things, in particular they could join with AMD and implement its as yet unrevealed 64-bit instruction set.
Oh please. You're not one of the few negative posters around slashdot, but you're certainly among the many negative posters that got moderated up - not because your comment was interesting, but you included the "I'm might get moderated down for this..." disclaimer.
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'm sorry to be rude, but duh. That's how marketing works. You emphasize on the fine points of your product, and you skim over the weak points. Even a moron would not try to shift that focus in their own product release.
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.
I sure as hell don't konw what's a "Microsoft/Apple/Intel love-in/press-conference", but if you're referring to the catchy marketing phrases, you might want to remind yourself that you ARE listening to a product release.
Transmeta is a privately-funded company. It's not a university research laboratory. They aren't presenting a research paper. They are a company, and they are trying to make money to make a return on their investment.
Also, their product is targetted at OEMs and computer manufacterers, which is why the technical details are in the press pack, and not the webcast.
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.
I agree. Those moderators that feed the heretic-wannabes really should stop. Sorry if I sound a bit harsh, but I really can't stand these "I have some pissed-off opinion to be moderated up" posts escaping my score 2 threshold anymore.
specs of the machines that ran them
peterrenshaw ~ Another Scrappy Startup
I've had a look through the site, but I can't see any mention of how well the Crusoe chips would work in parallel.
Given the low cost and power consumption, they'd seem to be a logical choice for making cheap parallel machines.
Does anyone know if they're able to run (closely) in parallel? (ie. sharing system memory and buses) ?
No.
:-)
But, you're probably the only one who didn't notice that those patents have been discussed, analyzed, rehashed, etc. for months in just about every technical publication on the web, as well as the subject of several Slashdot articles
Chris
San Francisco values: compassion, tolerance, respect, intelligence
Yes, there will be faster chips, but not with the battery. There is also room in rackmountable stuff.
Plus I am looking forward to high-end SMP laptops. Here the power savings is not as important as speed. (Think demos.)
No, Transmeta does have some good opportunities if they can execute well.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Why not, instead of investing 5+ years and tons of money etc... solving the problem for only the "mobile computing" market, solve the problem for every battery user in existance by making a better battery?
:-)
What do you think companies have been trying to do for years now? Progress has been made, sure, but longer battery life can be achieved at 2 sides of the equation:
1. More power
2. Less power-consumption
Now if you're a processor designer and you've got a team of engineers who specialize in processors, which side are you going to focus on? Furthermore, they benefit immediately from the side-effects:
1. Less heat (I like the idea of not having a lap-warmer in summer)
2. Less noise (no fan? or at least a quieter one?)
3. Less weight
Leave the battery design to people who specialize in that sort of thing.
Finally, I have to admit, saving power appeals to me much more than packing more and more power (a.k.a. heat-emission) into a device; think green
Chris
San Francisco values: compassion, tolerance, respect, intelligence
Exactly what hype are you talking about? Yes, the press has been talking about the stuff and people on slashdot have been speculating far more than they should have, as usual.
But there has been absolutely no hype, at least none generated by Transmeta. Of course, you could argue that their marketing department is just smarter and stealthier than that of most other companies. It might even be true, but still, all the so-called hype that has reached the consumers has been speculation and rumors. Not anything that Transmeta has said directly. You can hardly argue that Crusoe has been vaporware or something.
It's quite possible that you expected more from Crusoe. But I think it's kind of silly to hold Transmeta responsible for not living up to expectations people have built up based on rumors.
You're right. I didn't phrase that well. There's been an awful lot of hype from the rest of the community ABOUT what Transmeta has been working on, and that's what I'm referring to.
I was just expecting more then a low-power x86 clone, and that's all these chips are to the end user.
Actually, he did say that (sort of) in an interview some years ago -- something to the effect of "linux is in my contract."
> I want to see this processor running C bytecode. =^)
Huh, I want to see this translate a program into several languages, compile the all and see which is the fastest language to use.
dave
You forget, Linux, by his own admission, doesn't care about games.
He only cares about compiling his kernels.
Chas - The one, the only.
THANK GOD!!!
Chas - The one, the only.
THANK GOD!!!
Now it seems to me that the Crusoe processors that are coming first are mobile just because the intial ideas of Transmeta lend themselves well to that application. Has anyone else read the whitepaper and seeing what I think I'm seeing? It looks like they've just taken the back end instruction unit of a more traditional CPU to start. But rather then add microcode and transistor based software to control getting software instructions to it, they've moved those functions in normal software. This allows the actual CPU's to be cheaper, smaller, and simpler (hence the lower power requirements, in addition to their clever management scheme). But is it just me, or does this also provide a fascinating layer of abstraction? Couldn't the code morphing software just as easily be programmed to dispatch instructions to multiple VLIW cores? Not to mention all the advantages of being able to write more complicated software that can make better choices about how to optimize and keep the core processor running. Very interesting idea I think - lots of possiblities. It seems like it's essentially turning the x86 instruction set into an API, so bigger and badder advances on the silicon side of things can be taken advantage of without having to go crazy optimizing existing applications. Abstraction is one of the most powerful tools we have, and this is a fascinating use of it. Of course, they don't mention much about the extra RAM that translation cache and code morphing software is going to require - I wonder what type of cost this abstraction comes at.
as i read through various sources, i could not help thinking "yeah, it is low power and translates code, but P3's have been translating code in hardware which must be faster".
What IS the Power of Crusoe? Why is it so fast?
/. made everything clear. here it is:
1) Crusoe is so fast (almost equal P3) because the code morphing is done in software. software is slower per se, but it is a lot easier to use lots of memory for state caching, can be tuned easier, etc - all the reasons you would not want to have your average application program etched into silicone.
2) the true power of Crusoe is that actual silicone development is completely independent of previous iterations. if the next-best-thing-after-VLIW gets invented, they can put it into silicone in no time flat, while all other processor developers can only watch from a distance. WOW. WOW. WOW.
of course, there is also small die size (read: cheap!) and low power comsumption. but these advantages pale in comparison to 2, above.
If Transmeta can keep the competitiveness of the
chip up from a speed/computer-power standpoint, then vendors of RISC instruction sets will do a cost analysis of whether its cheaper to design their own processors or to design software to program Transmeta's. Licensing terms and Transmeta's ability to drive volumes would also be pivotal. They do give up some control, true, but this may be preferable to an Intel-only migration, since with Transmeta they can retain their ISA lock-in and binary compatibility.
--LP
Nobody builds processors that directly run the ix86 instruction set any more. Both Intel and AMD put out processors that execute RISC-like instructions at the core, and then surround it with a lot of machinery to translate the user level instructions into these operations on the fly. There's no reason why Transmeta's approach can't be competitive to that, especially given caching of translated instructions.
What we're seeing is the rebirth of microcode. This approach makes the most sense when executing a tightly coded instruction stream -- CISC instructions, or maybe bytecodes (there might be a performance advantage in doing JIT translation from Java bytecodes to VLIW instructions, but then again the combination of the two JIT translations, from bytecodes to ix86 and from ix86 to VLIW might be nearly as good and cheaper in the long run.
As I said above, source has nothing to do with the objection I'm raising. It has to do with putting restrictions on redistribution by your licensees.
... they are still emulating the x86 instruction set. Even with all their fancy technology a 700mhz processor will only perform, at best equivalent, to a 500mhz Pentium.
It is important to realize that the current Intel and AMD CPUs do not execute x86 instructions, either. They use hybrid RISC cores with front-end instruction decoders to break down the x86 CISC operations into smaller, RISC-style operations which can be more easily optimized.
So I wouldn't be so quick to dismiss Transmeta's performance claims as impossible simply because they are using emulation. If this was traditional emulation, I would agree with you. But it isn't.
In traditional processor emulation, you write a special program which sits between the host CPU and the "foreign code". This program reads the foreign code, figures out what it is doing, and does it. Essentially, you write a program to act like the foreign CPU. Not very efficient.
Transmeta's "code morphing" techniques, on the other hand, do something a little more intelligent. They start by translation of x86 to native instructions. So you are running native code, with an up-front penalty for translation. Then they apply selective optimizations to tune the translated code to the native design as needed.
Given time, that could result in much higher performance then traditional emulation. You might get very close to "native" performance by optimizing the code that matters in ways that apply to the native CPU.
Or you might not. There is very little hard data available right now, so all anyone can do is speculate. We can't say "Yes", nor can we say "No".
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Actually, the performance would probably be *WORSE*.
Why?
The Crusoe doesn't have out of order execution.
That is part of how the power requirements are so low..
A lot of the circutry that other cpu's have is handled by the software driving the processor. So, you would still need a crusoe to crusoe translator to resolve dependancies and do OOO.
Blessed are the pessimists, for they have made backups.
See, I've always said it like "may-ta", but in the conference they were clearly saying trans-met-a
how do you guys pronounce it, and are both ways correct? and not just for transmeta, but for meta-anything.
may-ta just sounds so much better to me.
No.. they mean 48C. Your celeron is running at 34 C (The F is a typo)... because it has a BIG HEATSINK AND FAN. The crusoe will run at 48C *without* any cooling.
And yes.. the PIII would.. well.. not melt, but possibly do some damage to itself... but it only runs at 113 C *without* a fan & heatsink.
Can some more intelligent people than myself comment on how these Crusoe processors might or might not be able to handle the Intel and AMD SIMD instructions (ie MMX and 3DNow!). Could this morphing use those, or are they proprietary and need to be licenced? If they're not I guess most apps would take a performance hit from not being able to use them?
Personally, I think the Transmeta CPU's are potentially the "tip of the iceberg" when it comes to CPU designs.
Remember, Transmeta has only shown x86 instruction set emulation; it could conceivably run another CPU instruction set (e.g., PowerPC G3 or G4). After all, if it takes only a little programming for the TM3210 or TM5400 to run Java almost like "native code"....
The very low power consumption of the Transmeta CPU means the elaborate and expensive CPU cooling needed for the mobile Pentium II/III CPU's are almost eliminated; this also means that battery life can be dramatically increased, which means that the "Internet appliance" shown at the demo today will become reality at a reasonable price.
By the way, the Transmeta TM3210 could form the basis of the "Internet terminal" most everyone forecasts to be popular in the next few years. Because of its lower power consumption, such terminals could be quite small, and could be fitted with USB, IEEE-1394, RJ-11 analog telephone and RJ-45 10/100Base-T Ethernet connectors. In short, it'll be just one flat panel box, with motherboard and a small HD in the box, plus external keyboard and mouse pointer.
It'll be interest to see if TM3210-based machines can compete against the Sony PlayStation2....
Raymond in Mountain View, CA
he was quoting a bowdlerized version of the original:
Obviously, from the extensive demo'ing Transmeta did today, their method of run-time recode and optimization works. But think of what else a dynamic microcode processor can do! The dominant x86 binaries run fine without recompile. When the dominant arch switches over to PPC/AMD64/IA64/TM256/etc, Transmeta adds a new flashed layer of microcode, and now our three year old 'IA32' Crusoe laptop will run Windows2004 for the SuperAlpha-III.
There is nothing that ticks me off more than buying a $12,000 workstation that will be useless in four years when the manufacturer decides to switch processor arch and no longer offers support.
.sig: Now legally binding!
I think you've missed the main thing that's wrong with Transmeta: it's the lack of a key vision as to the possibilities of an exponential market explosion based around their product. They're occupying the valley instead of conquering the universe. Let me explain.
... and 10 times the pity because the presence of Linus must have kept the benefits of community development pretty obvious within the company. A missed opportunity, possibly the biggest missed opportunity ever to occur in computing.
What's the single most important lesson that the computing scene has learned in the last few years? Hey, that's an easy one: that the massively parallel development in the Free/Open Software community outpaces that in even the best funded closed commercial teams by a huge factor, easily two orders of magnitude. The productivity is without peer, verging on the ridiculous by traditional measures.
Yet Transmeta is not opening up the development of Code Morphing Software to the community, apparently as a result of an incredibly regressive devotion to the antiquated concept of Intellectual Property and its laughable protection through obscurity or non-disclosure. So, instead of the next few quarters seeing a myriad of ports of CMS to dozens of architectures being attempted (and inevitably quite a few of them succeeding rapidly), we're going to be forever waiting on the closed Transmeta team to deliver. It's going to be the pits. It's going to be annoying. It's going to be slow.
Even worse, open development would be highly likely to optimize the hell out of the x86 version of CMS in very short order, far more rapidly than TM could despite their current great lead. You just can't hold back a thousand highly enthusiastic parallel streams of development, even if there is a substantial attrition rate. In contrast, now it's going to be a straight race between TM and Intel, and in this head-to-head between closed teams, only a fool would discount Intel despite the far greater ease with which Crusoe can be optimized compared to Intel hardware.
This is a terrible waste of a supreme opportunity. Transmeta could lay to waste all competition everywhere with Crusoe if they freed CMS from its appalling harness of proprietary development. Imagine all computing everywhere running on TM hardware, simply because Crusoe executes *all* instruction sets in current use. That's not an impossible vision, but it can't be achieved within a small closed group of developers.
What a pity
[And no, their portability/flexibility argument for not opening CMS and the VLIW architecture does not affect what I've said above, because whereas the porting of CMS for a single ISA to a new VLIW architecture can be performed effectively by their single centralized team, there is no way that this scales to porting dozens of ISAs to it. That can be done effectively only in a distributed manner. (The portability benefits of non-disclosure could have been achieved quite easily through a simple system of TM design guidelines.)]
I'm sad for what might have been.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
"Although Transmeta has a 128bit chip, they still emulate the x86 instructions, and are completely reliant on Intel setting standards."
...
:-) Besides, this has never posed a problem for AMD.. Being first to market doesn't always mean being best to market (K7 vs PIII).
I addressed this in another thread. So what if Intel decides night is day and white is black? It will only affect their instruction sets. If Intel goes and reverses the order of the argument bytes to the mov instruction, all they hurt are themselves. AMD and Transmeta both carry the x86 ISA torch along side Intel. They'd have to resort to another method to beat them, which leads
"Suppose Intel doesn't want to let Transmeta in on a prerelease stepping of the Merced chip?"
Intel has said before that the Merced is a 64-bit VLIW chip with a "powerful" core. In fact, they set the pricing point to be around 5 to 6 figures. I really don't think that'll clash with a low-end designed for embeded marlet processor, which uses a different simplified 128-bit VLIW core. The ol' x86 ISA doesn't get a look in anymore
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
So it's a reasonable implementation of an old idea. The interesting question is whether it works well enough that it can make up for the lack of speculative execution in the machine. From the documentation, Crusoe is a classic VLIW machine; the CPU executes one big word worth of instructions at a time, in lockstep. Visit the Transmeta web site for details.
... they are still emulating the x86 instruction set. Even with all their fancy technology a 700mhz processor will only perform, at best equivalent, to a 500mhz Pentium
That was a quote from a Transmeta employee. I do realize that Intel and AMD processors don't execute x86 instructions. However their vector units (MMX or 3DNow) are executed natively. The MMX unit is highly optomized hardware that takes advantage of all the latest hardware techniques. Therefore, even if MMX emulation was easy (I don't think that it is), it would still be slower because it would be emulated in software. You don't see as much of a penalty while emulating x86 instructions because CISC instructions are relatively quick to translate, and both the Athlon and Pentium are also emulating the x86 instruction set.
Sig goes here
Transmeta is a chip company. They have come up with a innovative new chip for use in a mobile platform. How that platform will connect to the internet, is up to the companies that implement the chip in their portables.
The internet connection could be something as simple as an ethernet jack that you would plug an ordinary cat-5 cable into, or it could be an Apple-stype airport wireless LAN connection.
Personally, I'm going to use a Ricochet wireless modem.
------------------------
Help me switch to Linux!
Stupid people will be persecuted to the fullest extent allowed by law.
The instruction sets are different - and the binary-to-binary translation software would then be different because it has to translate to a different instruction set.
However, as the Compatibility page on the Transmeta web site says:
so they're "binary-compatible" to the extent that they can both run x86 code.
Umm, Linux is a "popular PC operating system", is it not? Given that, the above indicates that Crusoe processors, plural, can run Linux.
For that matter, the Crusoe processor family page says quite explictly of the TM 5400 (that being the chip to which you're referring):
And then me and doubtless many others would haul him quite promptly to the nearest Supreme Court and batter him to death with a wet newspaper...
Open Source. Closed Minds. We are Slashdot.
The first part of this is, of course, hardly unique to Transmeta; binary-to-binary translation's been around for ages (dating back at least to the IBM System/38, compilers for which generated a very CISCy pseudo-instruction set that got translated to the native instruction set by code running on the machine; the AS/400's continue to do this, which made it easier for them to switch from the older S/38 and AS/400's with their 360-ish instruction set to the newer AS/400's with an extended PowerPC), and it was also used, I think, by HP to migrate users from the 16-bit stack-machine HP 3000's to the 32-bit PowerPC HP 3000's, and Digital's^H^H^H^H^H^H^H^H^HCompaq's FX!32 translates x86 Win32 programs to Alpha Win32 programs.
A Smalltalk implementation for the 68K, by L. Peter Deutsch (yes, Mr. Ghostscript), translated Smalltalk bytecodes to native 68K instructions, and, of course, Java just-in-time compilers do that as well.
I have the impression that FX!32, at least, would do post-execution optimization of the generated code based on profiling.
What I think is new about Transmeta's stuff is
FreeBSD runs on x86-compatible processors, does it not?
The Crusoe processor family page on the Transmeta Web site says of the lower-speed processor:
and says of the higher-speed processor:
They don't explicitly mention FreeBSD - or NetBSD, or OpenBSD, or BSD/OS, or SCO UNIX, or SCO Unixware, or SCO Xenix, or OS/2, or BeOS, or Solaris, or Coherent, or... - but those are all part of the "complete range of x86-based operating systems".
As far as the BIOS/PROM monitor, the OS, the applications, etc. are concerned, it's just another x86 processor.
If it dumps support for the 16-bit instructions, it doesn't offer "full x86 compatibility".
However, the Crusoe processor family page says that the TM3120 does offer full x86 compatibility:
so they don't "dump" the 16-bit instructions in the less-expensive chip. It may not handle 16-bit code as efficiently the more-expensive chip, just as a product from another maker of x86-compatible chips punted on handling 16-bit code efficiently (but said maker had to fix that in the Pentium II because the P6 was to be used in PC's, not in appliances without the problem of legacy apps; the PPro might have been able to get away with it as it was primarily intended for high-end machines running NT and Win32 apps).
The first time a chunk of code is run, there's a performance hit as it's translated to the native instruction set for the particular chip on which it's running. The translated code is cached, so the next time it's run, if it's still in the cache of translated code, there's no performance hit for translation.
Given that IE plugins tend, as far as I know, to be x86 Win32 code, and that not all CE machines have x86-compatible processors in them, at least some of them almost certainly can't run those plugins.
A machine running an x86-compatible processor from a supplier other than Transmeta could do that, too - but presumably the idea is that such a machine might have higher power consumption than one might like (although there is at least one mobile device with an x86 processor in it - the Nokia 9000 family of mobile phones on steroids - although I think it's an embedded x86 and may not be capable of running most x86 OSes; I think the 9000's run GeoWorks).
Definitely true for Solaris and BeOS, given that there are versions of both of those OSes that run on the instruction set from which Transmeta's binary-to-binary translation code translates.
MacOS X is another matter, unless Apple release an x86 version of it.
Perhaps the underlying VLIW engines on the two chips aren't so specialized to serve as targets for translation from x86 that SPARC-to-native or PowerPC-to-native compilers could be written, but I wouldn't hold my breath waiting for those translators - I'd punt on MacOS X and get x86 versions of Solaris or BeOS instead.
Digital have done a binary-to-binary translator that (as I remember) can instrument the translated code (or otherwise observe its behavior) and retranslate based on that, but:
Sure, if it runs under WINE, or if you run VMware on the OS the machine booted under, and run the other OS under VMware, or something such as that. :-)
What Crusoe provides is a processor that looks, from the standpoint of the OS and stuff running atop it, just like any other x86 processor, but that implements the x86 instruction set by dynamically translating code from x86 to the native instruction set of the particular chip. It's not providing, from what I've seen on the Transmeta Web site, any magical ability to run two OSes simultaneously, or to run apps from two OSes simultaneously, beyond what you can do on any other x86-compatible processor.
True of a PC running just about any x86 processor, not just a Crusoe (as long as the system doesn't have features that some OSes don't support and that have to be supported, e.g. USB keyboards, which aren't, as far as I know, supported by one well-known PC OS...
...Windows NT 4.0).
True of a PC running just about any x86 processor, not just a Crusoe.
Did they really claim that they could do this any better than any other x86 processor? You can run Java apps on Windows on x86 (or Linux on x86, or...) now - as far as I know, you can even do it with a JIT compiler.
Motorola first "went RISC" with the 88000. I forget whether they pitched the 88000 to Sun, but Sun didn't bite - they rolled their own, SPARC.
It went into some machines - I think Omron had an 88K workstation, and Encore had 88K-based superminis - but, for better or worse, didn't catch on big enough to survive; Motorola eventually dropped it after joining up with IBM and Apple to do PowerPC.
However, I don't see how this was like the 88000, which was a RISC chip, and which didn't use the RISC instruction set solely as
but provided it as the instruction set that assembler-language programmers and compilers generated.
Wouldn't this processor be great for Overclocking enthusiasts or is there something obvious that would get in the way of this.
If it runs at 48deg C at 700Mhz then can't we boost up the clock speed a little?
May not be much good for mobile computing, where Transmeta seem to be focusing, and the CPUs won't be available to end-users (nor will the equipment), but isn't the potential there?
To be honest I would like to see something run natively on VLIW instructions, surely that would rock!
The universe can be anyone's as long as they agree to distribute it under an Open Source license, eh?
Cmon... give me a break. Simply put, it does not pay to tell your competitors all your secrets. Yes Open Source has it's benefits, but when you are running a business, it pays to sacrifice some of this flexibility for increased profit. Just ask Bill.
This is even more of a concern for a company which has done nothing but R & D for five years (i.e. SPEND money).
Best regards,
SEAL
Key phrase: the compatibility is very important for closed source software but unimportant for open-source type where you can easily recompile. You really expect the average user to recompile their software? Not going to happen, sorry.
I agree, StrongARM would be a good one if they could find a way of getting it into this sort of market. They don't seem to know how to yet, though.
Greg
Greg
(Inside a nuclear plant)
Aaaarrrggh! Run! The canary has mutated!
Seeing as the power consumption is so low, couldn't someone put two or more Crusoe chips in a laptop, increasing the performance, while still having a superior battery life to anything that's currently available? Also, the code morphing software could perhaps be adapted to make all applications run multi-threaded, regardless of how lame your OS is. These boys have really cooked up something special with this chip.
So, what does transmeta mean for the Oxygen project at MIT? I heard Deterzous' talk at RSA keynote on the handheld cellphone/palm-pilot/pager/etc.etc/ that links up to a stationary system (desktop)--I'd bet that the Crusoe will be the backbone behind Oxygen (I'd be surprised if there isn't some collusion already) and if not the Oxygen system, some decent portable connectivity device.
Returned Peace Corps IT Volunteer
Yes, the first SPARCs were fabbed by Fujitsu; the first full-custom SPARC (7C601) was done by Cypress.
As I remember, the RT PC came out after SPARC - I remember people waiting in fear at Sun because they didn't know whether the RT was going to crush them like a bug.
It was called ROMP, for Research and Office Microprocessor; I guess the "Office" part indicates that it was intended for office equipment such as word processors, etc..
Right - it was used in the DG Aviion machines, as well as the nes I mentioned.
I seem to remember hearing (from a comp.arch posting by John Mashey, I think) that Motorola pitched the 88K to MIPS as well as to Sun.
...based on IBM's POWER (Performance Optimized With Enhanced RISC - yes, really; some marketoon must've gotten a bonus for that one) architecture, which was their attempt, after the ROMP and a second generation thereof; the first POWER chip (RIOS) did a fair bit better than the ROMP, performance-wise.
I think the Precision Architecture antedated Alpha.
Unless Win 3.11 or DOS are not "standard x86-compatible operating systems", the note on the TM3120:
sure seems to imply that the TM3120 can run Windows 3.11 and DOS code.
You assume incorrectly - the people who seem to think that they haven't stated pretty clearly that both chips are completely x86-compatible seem to me to be trying, for some unknown reason, to read something into Transmeta's statements that isn't there, and I don't think it's particularly worth Transmeta's time and energy to worry about people who choose to read "the complete range of x86-based operating systems" or "Fully x86 compatible" in non-obvious ways.
There's more to consider here...
1.What Transmeta is doing isn't truly emulation, at least as it is traditionally known. In, say, a Pentium III, the chip uses hardware to decode x86 into a series of internal RISC-like operations. This decoder hardware is a huge beast, taking up a tremendous percentage of the overall silicon and is responsible for most of the power consumption issues. In Crusoe, however, Transmeta moved most of the decode functions to a low-level software layer. Which, being software, has the *potential* to inhibit performance, though saving power. However, they suddenly don't have this huge hardware decoder to deal with, and so can devote that silicon to extra execution units (integer, FP, etc). Which will help increase performance significantly. Whether this is {enough/not enough/more than enough} to compensate is an interesting question, which I don't really think any of us have enough info to truly answer just yet. Also keep in mind that the decode hardware a la PIII can have a negative effect on the sorts of clock rates you can achieve, so moving it to software may help with that as well. Complex decode hardware also forces a larger branch penalty in case of a branch misprediction.
2. Not only can they devote extra silicon to execution rather than simply decoding, but doing the software translation to native VLIW adds further performance benefits. The first of which is this: it allows Crusoe to perform optimizations on the incoming code which would be impossible with a purely hardware chip.
One of the biggest of these is dead code elimination. x86 compilers commonly save a variable out to memory, then load it back in shortly thereafter - this is because of the very limited number of official, or "architected" x86 registers. The compiler thus ensures that it always has the correct register values. Much of the time, though, the load is unnecessary because the register wasn't modified (the compiler was just being conservative). Transmeta's Code Morphing software can detect these situations and actually remove unneeded loads, something that no purely hardware solution can match. And loads tend to be a big performance inhibitor; due to the long memory latencies, as well as the fact that loads typically start long dependency chains, where subsequent instructions require the load to finish before they can start.
There are several other compiler-like tricks that the Transmeta software can (and does) perform in realtime (and with runtime data that compilers don't possess) that can greatly speed up the performance of code.
3. Also, consider this: traditional x86 chips have had to decode instructions every time they execute. This is a pretty big overhead. Crusoe actually caches intructions in decoded, optimized form in a hardware "translation cache". This means that while yes, you do a software decode once, which could be slower than a hardware decode, you only have to do it that one time, versus every time with hardware decode. Thus the cost of software decode is amortized over many many cycles, and might actually be more efficient than hardware. (think about it: 99.99% of the time you're going to be executing native, optimized VLIW instructions coming from the translation cache. Only the remaining small bit of time do you actually have to decode).
4. There is also something to be said for the fact that this chip is targeted at the mobile arena. It's not meant to be the desktop/server powerhouse. The needs of mobile consumers are different. Mobile uses typically use only a small fraction of the processor's capabilities, so even *if* the Transmeta chip was slightly less strong on benchmark performance vs a PIII, it's overwhelming superiority in power consumption still makes it a big win, since you can't notice the slight performance difference anyway. Probably the most taxing thing you might do with the laptop is play DVDs or something similar, which the benchmarks show Crusoe handles just as well as a PIII - and at a fraction of the power.
Oh, and just as a side note: CISC instructions are most certainly not "relatively quick to translate". One big reason behind Crusoe's existence is that CISC decode/translation is a difficult, long-latency operation, that uses a lot of hardware. Mostly because of the variable-length instructions, which forces the processor to use a largely serial decode process. Which eliminates the primary advantage - parallel processing - of hardware. Said decode hardware could be put to better uses. MMX/3DNow instructions are probably easier to translate, being a newer, cleaner extension to the instruction set. Execution may very well be more difficult than standard x86, but the translation itself shouldn't be that bad.
What would "a Crusoe version" of a platform be? Something built to run on a particular Crusoe chip (the two chips Transmeta have mentioned apparently do not have the same instruction set)? Or something built for some instruction set implemented atop various Crusoe chips (with different translators)?
...but doesn't run Windows. If the market for low-power machines that run Windows (or other OSes not available for mobile machines with other types of processors) is sufficiently large, and if other x86 processor vendors don't get (as others have said) "good enough" power consumption, and if a lower-power CPU makes enough of a difference if the other components have the same power consumption no matter what processor is used, then they might have a chance. Time will tell.
As for the ability to run multiple instruction sets on the same machine, that may be of interest, at least for some OSes, only if you can run in a "virtual machine" environment, so you can run Windows and MacOS on the same machine, unless Transmeta relase to the vendors of one or the other of those OSes enough information to let them use the instruction-set switching directly and those OS vendors are willing to modify their OS to be able to run applications for other processors/OSes without just running the entire other OS inside a virtual machine.