Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Transmeta

UPDATED: Transmeta's Crusoe Unveiled 768

I've gotten the first round of details about Transmeta's *two* new chips (Thanks Chris!). It's very cool - x86 compatible, Linus has written "Mobile Linux" to run on the chip, and totally insane power consumption. Click below for details - and we'll be updating this story throughout the day so check back again for more. Update: 01/20 02:33 by E : David Cassel, who was at the unveiling, sent in his notes and some great quotes from the unveiling. His take is appended to the end of this article.

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."

This discussion has been archived. No new comments can be posted.

Transmeta's Crusoe Unveiled

Comments Filter:
  • by Hoonis ( 20223 ) on Wednesday January 19, 2000 @10:43AM (#1357019) Homepage
    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?

  • by c.r.o.c.o ( 123083 ) on Wednesday January 19, 2000 @10:47AM (#1357029)
    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?

  • by ctembreull ( 120894 ) on Wednesday January 19, 2000 @10:50AM (#1357039)
    So, Linus has written "Mobile Linux" for these chips. The chips themselves are low-power and
    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.

  • by dreamchaser ( 49529 ) on Wednesday January 19, 2000 @10:50AM (#1357041) Homepage Journal
    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.

  • by mdtanx ( 132628 ) on Wednesday January 19, 2000 @10:50AM (#1357042)
    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.
  • by rogerbo ( 74443 ) on Wednesday January 19, 2000 @10:51AM (#1357043)
    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?
  • by Signal 11 ( 7608 ) on Wednesday January 19, 2000 @10:55AM (#1357049)
    You can find my (mostly) complete notes at this [slashdot.org] link. Executive summary follows --
    • Transmeta is focused on software, not hardware.
    • Strategic alliance with IBM for the hardware.
    • Two product families, both focused on mobile computing.
    • Linus got his ass kicked by the CEO in quake. =)
    • code-morphing - 75% of the "processor" will really be in software - translating everything down to the actual processor's internal instructions.
    • VERY low power consumption, somewhere around 1 watt during normal use. Less than a few milliwatts for "standby" mode. You can leave this thing on for weeks without difficulty. On a battery.
    • Transmeta website will be live at 2:00 CST, 12:00 PST, and 3:00 EST (for those who can't convert like me. *g*)
    • Linux will have the code-morphing code added in, as demonstrated on the webcast. However, no kernel patch is forthcoming - yet. Linus will likely make an announcement within 24 hours of this webcast (However, this is my 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.
  • by MTO ( 2039 ) on Wednesday January 19, 2000 @11:00AM (#1357069)
    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.
  • by dougman ( 908 ) on Wednesday January 19, 2000 @11:00AM (#1357070)
    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

  • IBM's Travelstar IDE drive uses a max of 5.0W @ +5V at startup. Typical is about 2.5-3.0W @ +5V. I'm not sure what voltage is used for the PIII (5.0 draw or what actually gets to the PIII, which is about 1.x V), but it'll be more than that.

    There was mention of two types of laptops, one without removable media that would be less than 3 lbs. To me, removable media is probably the most power hungry (constantly spinning up CD-ROMs and floppy disks can really chew up battery life).
  • by rogerbo ( 74443 ) on Wednesday January 19, 2000 @11:04AM (#1357077)
    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.
  • Did anyone watch the Webcast? The Associated Press goon didn't seem to be paying any attention whatsoever.

    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.

  • by Outland Traveller ( 12138 ) on Wednesday January 19, 2000 @11:06AM (#1357082)
    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.
  • by Matt2000 ( 29624 ) on Wednesday January 19, 2000 @11:13AM (#1357094) Homepage
    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 [hotnutz.com]
  • by Don Negro ( 1069 ) on Wednesday January 19, 2000 @11:17AM (#1357102)
    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
  • by rjamestaylor ( 117847 ) <rjamestaylor@gmail.com> on Wednesday January 19, 2000 @11:20AM (#1357107) Journal
    I agree with your excitement. I've wanted a truly portable Internet-capable device for a long time. the characteristics of this technology are not fully realized (which means there is much potential for growth). I have much hope for this technology (and company).

    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).

    :-only kona in my cup-:

    :-robert taylor-:
  • 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.
  • They also said that the VLIW instruction sets are different for the TM3120 and TM5400 chips, the Code Morphing Software has different back-ends for each chip (and is compiled to different targets).

    But yeah, unless/until Transmeta releases the specs or someone reverse-engineers the instruction set, we won't see any do-it-yourself CPU emulators.

    They did mention that one of the demos was a Crusoe running Java bytecode 'natively' (ie CMS translating bytecode directly to VLIW), so perhaps we will see some other CPU emulations in future.

    However, the current architectures (and it wasn't clear whether this was of the chip or of the system the chip is in) don't seem to allow for dynamically switching instruction sets - once the thing has booted up the CMS code the pathways to that low level stuff are closed.

    This makes sense for Transmeta at this point to keep the market from getting confused, but I hope that once this settles out that they start looking at making the thing more flexible.
  • by rogerbo ( 74443 ) on Wednesday January 19, 2000 @11:25AM (#1357122)
    -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.....

  • by franl ( 50139 ) on Wednesday January 19, 2000 @11:30AM (#1357132)
    rogerbo wrote: 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.

    Linus said that they explicitly decided against doing a native version of Linux for the Crusoe. The whole idea of Crusoe is to keep you from having to recompile while still letting you take advantage of advances in the underlying CPU architecture. Nobody should want a native Crusoe application, because when a new Crusoe comes out with different instructions or whatever, you'll have to recompile. As much as I hate the phrase, this is really a paradigm shift in processor and OS technology.

    The lack of a SPARC or Alpha or PPC morphing layer is probably more a pragmatic decision on Transmeta's part. They can't do it all (right away). They didn't rule out a morphing implementation for PPC, Sparc, etc., but they get the most bang for their buck from doing the x86 first.
  • by Matt2000 ( 29624 ) on Wednesday January 19, 2000 @11:30AM (#1357133) Homepage

    A question: because of the Crusoe code morphing technology does this mean that we could program it to translate Java byte code into the Crusoe VLIW instruction set and get a hardware speed JVM? That would be sweet...

    Hotnutz.com [hotnutz.com]
  • by ChrisRijk ( 1818 ) on Wednesday January 19, 2000 @11:31AM (#1357138)
    I managed to see most of the broadcast, but missed about the first hour's worth. Anyway, it has some interesting similarities with Sun's MAJC architecture [sun.com] design:

    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

  • by Anonymous Coward
    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 !)
  • It's not a fork in the kernel tree. Crusoe only 'emulates' x86..

    It is no Mobil Linux it's just some patches for the kernel, made by Transmeta.

    They will be released 'soon'..
    Mvh
    --
    Magnus
  • Well the 400MHZ version comes with linux, the 700MHZ version comes with windows. The 700MHZ supports 16 bit better, they 400 doesn't. 16 Bit support slows down a system. the 700MHZ runs windows perfectly and is exactly x86 compatible. Anything that is 100% x86 compatible can run x86 linux. But I'd be willing to bet that on linux the 700MHZ with 16 bit support runs exactly the same speed as the 400MHZ without 16 bit optimization as linux doesn't need this. (I assume both support 16 bit, just one is optimized for it, ruducing its speed/MHZ.)
  • Is this a technical violation of the GPL?

    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):

    7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
  • 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.

  • by Percible ( 39773 ) on Wednesday January 19, 2000 @11:43AM (#1357153) Homepage
    Judging by the following URL -

    http://www.transmeta.com/mobile/ [transmeta.com]

    Looks like someone at Transmeta likes Slashdot, too.
  • Well, isn't that exactly what they are already doing? How can a "ubiquitous consumer machine" get any more ubiquitous than a cordless webpad?

    If you really want a kiosk form factor so badly you can take the webpad and stick it on the front of a big, empty box.


    ----
  • by sjames ( 1099 ) on Wednesday January 19, 2000 @11:48AM (#1357158) Homepage Journal

    Will this chip have the same hard time to enter the market?

    Probably not. The Athlon is a fine CPU, but it's advantages over PIII are not huge (reletivly speaking).

    Crusoe on the other hand isn't that fast (but really, 500Mhz equiv. isn't all that slow either), but it's power consumption is 1/35 that of PIII. That translates DIRECTLY into battery life which has been the bane of laptops from the beginning. Add in to that that a fan isn't needed and you really have something. The lack of a fan is more significant than it seems. Lack of fan means lack of vent holes (with good heatsink technique) which means a sealed case that can tolerate wet conditions MUCH better than a laptop with a fan.

    It opens the door to a new class of handheld device. The PalmVII is great (I use one myself), but compared to the Crusoe, it's CPU is absolutely anemic. So in it's niche (tiny laptops and handhelds), it really is tremendously better than the competition.

  • 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.


    ---

  • by Anonymous Coward
    Er, 48 degrees is around 120F. You have a celeron running at close to (h2o) freezing temps? Sorta doubtful.

    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.

  • by LinuxParanoid ( 64467 ) on Wednesday January 19, 2000 @12:02PM (#1357180) Homepage Journal
    I learn things through critique. Given all the hype, what is the counter-case? In the interest of eventually reaching a balanced perspective, here's what looks wrong with Transmeta to me:

    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


  • Since it will be able to run any x86 OS, it should make the transition from windows to linux easy for windows user, plus it will make it possible to easily switch between several OS's such as linux, bsd, be, java, etc.

    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.

  • by tdsanchez ( 15549 ) on Wednesday January 19, 2000 @12:07PM (#1357190) Homepage
    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
  • The Pentium II and above series processors have the ability to upgrade their microcode at boot time. It requires a signed hunk of code and is only possible during a short period before the rest of the chip is initialized, but it is there and available.

    I think the PPro might also have it but I'm not sure.
  • by Anomalous Canard ( 137695 ) on Wednesday January 19, 2000 @12:15PM (#1357200)
    Just judging from the screenshot [transmeta.com] 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
  • by Kaa ( 21510 ) on Wednesday January 19, 2000 @12:16PM (#1357202) Homepage
    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
  • by Kaa ( 21510 ) on Wednesday January 19, 2000 @12:17PM (#1357204) Homepage
    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
  • by dattaway ( 3088 ) on Wednesday January 19, 2000 @12:21PM (#1357211) Homepage Journal
    And a mirror of the mirror is mirrored at http://www.attaway.org/~ dattaway/www.printf.net/transmeta/ [attaway.org] as well as the irc transcripts. Enjoy!
  • by Gurlia ( 110988 ) on Wednesday January 19, 2000 @12:22PM (#1357212)

    Hmm, this raises an interesting thought: Would Crusoe eventually replace other architectures? Since it can simply run different Code Morphing software to emulate every existing architecture out there, why can't we code directly for Crusoe's native instruction set?? We don't need other architectures at all...

    I understand that one advantage of *not* coding directly in the native instruction set is that Transmeta can totally revamp the instruction set and simply release a new Code Morphing software... but still, while a particular release lasts, why not take advantage of it?

    Taking this further, Transmeta *could* release a "static" external instruction set that the Code Morphing software translates into whatever the current native set is. Then we don't need other architectures *at all*. All we need is to use this static external instruction set. We don't even have to worry about being compatible with future releases of Transmeta, since the Code Morphing software takes care of that.

    To conclude... WoW! I think Transmeta could be hitting something real big here... congrats!

  • 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.

  • by Scrybe ( 95209 ) on Wednesday January 19, 2000 @12:33PM (#1357228) Homepage

    During the Q&A session someone asked how the performance on the crusoe compared with that of the P!!!. After a bunch of normal disclaimers about different system configs, beta silicon, and beta x86 decode software they finally equated a TM5400 @ 667Mhz to a p!!! @ 500. Not bad for code morphing in a beta state plus all the potential power savings.

  • by Kaa ( 21510 ) on Wednesday January 19, 2000 @12:36PM (#1357229) Homepage
    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
  • I wonder how this competes with the strongARM [intel.com] processor:
    • 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 [kodak.com] and SSD [westaimadt.com]), 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.

  • 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...
  • by AJWM ( 19027 ) on Wednesday January 19, 2000 @12:43PM (#1357235) Homepage
    Some highlights from the technology whitepaper [transmeta.com] 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.


  • TM312 0 Data Sheet [transmeta.com]
    TM540 0 Data Sheet [transmeta.com]
    FAQ [transmeta.com]

    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 /.'d than Transmeta is right now! LOL
  • 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...

  • by sjames ( 1099 )

    You and me both!

  • >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).


    AFAIK, Q3A does not have a software rendering mode, you either need a Matrox 200, Matrox 400 or a Voodoo 2 to be able to play the game at all using Mesa. I know that some people have been able to get a Q3A 'slide show' by fudging a libMesaGL.so into the game directory, but this gives about a frame every three seconds.

    If something like this was done and it rendered in software at anything near an acceptible framerate, I am _really_ impressed. Seems more likely that there was a Matrox card running some type of GL implementation?

  • 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 [transmeta.com]

    Interesting stuff.
  • Well, what about a Mixed mode solution, akin the the MacOS? Programs could run in translated mode at regular speed, and portions of them could be translated to the full VLIW instruction set. It semems that Crusoe is already dynamically recompiling x86 to it's own instruction set, so, with smarter compiliers coming (which intel is funding), wouldn't it only add to the performance?

    After all, if intel's tools are indeed open-source, then it shouldn't be hard to add support for other VLIW instruction sets to the compiler. Of course, that would all hinge on Transmeta releasing the instruction set...

  • This isn't a bad critique, but to me it looks like the improvements Transmeta has acheived in power consumption could really enable smart, powerful, application machines that are worth something. PC's that now cost $1000 or less can be replaced with tablets that have browsers and a few office apps on top of Linux. Let's face it, that would meet the computing needs of 90% of the populace, and having no fans makes them much more home and SOHO friendly. Storage is the only remaining obstacle to having nice little machines that do all this, and there is hope on that front as well (I seem to remember reading about a technology for 2300GB, solid state, deck-of-cards-sized, $200 drives in the next two years - just imagine your portable MP3 collection!). This might be a better way for Linux to bury windows - start with WinCE and work from there.

  • by um... Lucas ( 13147 ) on Wednesday January 19, 2000 @01:05PM (#1357262) Homepage Journal
    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.
  • I think the idea is pure genious. Add new cpu instructions by downloding new code. Runtime optimizations. Intelligent power consumption.

    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.

  • by pnagel ( 107544 ) on Wednesday January 19, 2000 @01:09PM (#1357268)
    Crazy as it may sound, even if you do code straight to the native Crusoe instruction set, you would still need a Crusoe-to-Crusoe "code morphing" layer to get full performance.

    Remember, their chips' have no out of order execution units; they do this all in software. Instead of having lots of silicon to do agressive instruction scheduling optimizations on each instruction every time round a loop you re-execute the same old instruction again, their "code morphing" layer gets to lazily decide when to put in more effort into instruction recoding as it becomes obvious that a section of code need it.

    And the beauty of it all is that these instruction translations are saved in memory - you get to preserve a lot more state, you get to save instruction sheduling decisions, whereas silicon has to always repeatedly make those decisions over and over again as it reexecutes the same instruction.

  • The Athlon is a fine CPU, but it's advantages over PIII are not huge (reletivly speaking).

    I guess that depends on what you mean by "relatively speaking"...

    The Crusoe certainly would appear to have a huge edge over the Pentium in terms of cost and power consumption, which will particularly give it an edge in mobile and low cost applications. It's real competition in the non-x86 arena is probably the ARM.

    However, in it's own domain - high end systems - the Athlon *does* have quite an edge over the PIII. It has 3 integer execution units compared to the PIII's 2, plus 3 floating point execution units again compared to 2 for the PIII. Just as importantly, unlike the PIII the Athlon actually has the unrestricted ability to simultaneously issue the instructions to keep those execution units busy.

    There's a full PIII vs Athlon comparison over on Ars.
  • by Inoshiro ( 71693 ) on Wednesday January 19, 2000 @01:12PM (#1357273) Homepage
    "It's the code-morphing that makes it compatible right? Or is there some deeper compatibility at the hardware level?"

    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 :-) 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).

    "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.
    ---
  • They're not trying to make the "newest fastest
    most-expensivest" processor - they're going to
    viable portable devices (1.5-2 hours is not
    viable :>). Sure, a PIII 500 isn't the fastest
    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.
  • by ecampbel ( 89842 ) on Wednesday January 19, 2000 @01:35PM (#1357285)
    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.
  • Please ignore the complete assholes who are flaming you for an obvious typo. Anyone with a three-digit IQ knows you meant 34C.
  • by ecampbel ( 89842 ) on Wednesday January 19, 2000 @01:45PM (#1357291)
    You're kidding right? Remember that a Transmeta processor needs to translate EVERY instruction to an equivalent sent of 128bit instructions. This carries a significant performance penalty. Also, the Transmeta chip doesn't have any of the multimedia enhancements that Petium's, Athlon's, and G4's carry with it. Software does not beat hardware when doing extremely optimized vector based instructions that can run in parallel inside the native processor.
  • 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?
  • 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.
    ---
  • by RebornData ( 25811 ) on Wednesday January 19, 2000 @02:07PM (#1357312)
    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.
  • by Tjl ( 4493 ) on Wednesday January 19, 2000 @02:10PM (#1357314) Homepage
    I don't understand why everyone wants so much to run on the "native" 128-bit VLIW.


    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 was the first question that the person from Slashdot (forgive me, I can't remember who it was). The response was there was a demo there (not shown on the ZDNet broadcast) of a machine running X86 byte code and Java bytecode natively, at the same time.

    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 [slashdot.org] thread (starting at post #44) from September 23rd.

    Too bad they didn't give out prizes for guessing right. :-)

  • However, in it's own domain - high end systems - the Athlon *does* have quite an edge over the PIII.

    Vigorously agreed. I'd like to have a few myself. The comparison at Ars cemented my opinion that AMD is to be taken seriously in the high end PC market. It also made me consider them for a Beowulf cluster (I suppose that HAD to come up eventually :-).

    The difference is that Athlon's advantages do not make the impractical become practical or create a new class of machine (though it does make PCs much better). No combination of Athlon's advantages add up to a 35 to 1 improvement.

    ARM is close to the mark. It does solve the power problems and run cool. The one thing that relegates it to a niche market (for now anyway) is that it won't run most consumer software out of the box. That's not a big deal to me, I have source for all of the software I use and it runs Linux! But it does limit mass appeal which limits my chances of finding a nice ARM based laptop I can afford.

  • by bhurt ( 1081 ) on Wednesday January 19, 2000 @02:23PM (#1357324) Homepage
    On the other hand, Intel is going to try to switch architectures here in a year or three, from the old x86 to the new IA64. This is a vulnerable time for Intel- if you're moving onto a new architecture, why not move onto the best one available? This is the best time in the last couple of decades to launch a new CPU.

    I'll agree that the odds are still against them. Too many people buy on the basis of MHz rating and "Intel Inside". But they have a shot...
  • by Smack ( 977 ) on Wednesday January 19, 2000 @02:46PM (#1357345) Homepage
    Well, I'm sure this will fall on deaf ears, but here are some responses.

    I think their concept is low power, similar performance. So why would they brag about their similar performance if that's not their selling point?

    Did you watch the technical briefing? The one that followed the press conference? It was much less jargony. Sometimes companies have to play to their audience. Quotes like you gave are the only things the reporters understand sometimes, and most people don't get their news from Slashdot, so the reporters have to understand.

    Also, Transmeta isn't quite as vaporware as you make it sound. Having production silicon from IBM is a lot different than just having software simulations (like that Russian company a while ago). Since they aren't selling to end users, it's real hard to tell whether these are actually obtainable right now. If no one release a product using them before the end of Feb, then you can start shouting Vaporware.

    And that cheap fanatic comment at the end does make you a flamebaiter. Really, it does. Look in the mirror.
  • by tj2 ( 54604 ) on Wednesday January 19, 2000 @02:48PM (#1357347)
    Your points regarding the Transmeta chips are well taken. However, a couple of points:

    1. Power efficiency is a lot, but it isn't everything. I think the big win here is lower power draw than Intel, while offering x86 compatability that StrongARM doesn't have.

    2. Clock speeds are becoming less and less of an issue. Let's face it, there's damn little software of interest to the average consumer that's actually going to need 800+ MHz. Yeah, yeah, I know, wait until next year, today's screamer is tomorrow's piece of junk. But Transmeta is also free to increase clock speeds and improve their chips.

    Most of the market they seem to be aiming for is concerned with web access and email, not video editing. I think these chips will have the power for that.

    3. As for mobile access to the net, check out www.metricom.com [metricom.com]. They make the Ricochet wireless modem, which is currently in the process of rolling out a 128kbps network to about 46 cities. Metricom had a successful beta of the network last year and secured about $600 million in financing from Paul Allen and MCI/Worldcom for the rollout. I've used the older Ricochet modems (28.8kbps), and they worked like a charm. And they use flat-rate pricing, which is critical for mobile users, IMO.

    4. Why do they have to combine with AMD or someone else? They're not a chip fab, they're a design shop. I expect that they'll partner with whoever wants to make the chips, which will depend on consumer demand. We'll see.

  • by ecampbel ( 89842 ) on Wednesday January 19, 2000 @02:54PM (#1357351)
    I do realize that Transmeta does an excellent job in translating x86 instructions. Probably the best job that has ever been done. But 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. Java's developers have spent years trying to optimize their JIT, and it still is a lot slower than running native compiled C code.

    Their emulation tricks will not work on MMX or other instructions nearly so well. Curose can't make up the time it takes to emulate the instruction set by having better hardware. MMX and the G4 vector processing units utilize many of the same tricks that the entire Cursoe processor utilizes such as long word instructions, parallel processing and other optimization techniques. Also, the hardware of these multimedia units are explicitly optimized to process these special instructions. This means to emulate these instructions would drastically slow down the chip.
  • by ToLu the Happy Furby ( 63586 ) on Wednesday January 19, 2000 @02:59PM (#1357357)
    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?

    Actually, if you read their web site, Transmeta gave their "opinion" on this right here [transmeta.com]. Essentially, the gist of it is that the battery savings are quite significant, even on one of those giant laptops with the 15" screens and the DVD players, and even while playing a DVD in software (which, because it requires a nearly constant (and rather hefty) level of CPU power, can't take much advantage of their technology which dynamically scales down power usage and voltage to meet the current system needs).

    Basically, according to the tables on the above page, the worst-case for a Crusoe processor--running soft DVD (2 watts used in CPU + Northbridge) on a bigass notebook (8 watts)--gives 3.2 hours battery life. IIRC, one of those new G3's (and remember, a G3 consumes *way* less power than any (native) x86 chip) can barely manage an hour and a half.

    Plus, they're not even taking into account the fact that unlike any other notebook on the planet, these suckers don't need a fan; that should be reflected in the 8 watt system overhead, but isn't. (Not sure how much power a fan takes, but it has to be significant.)

    Now...in the normal case, in which the CPU is at full throttle only a little bit of the time, then Crusoe starts to clean up. For one thing, as they point out, traditional notebooks try to conserve power by just shutting off the CPU when it's not being used. The problem with this is it doesn't help the normal case when it's being used only a little bit, and it adds a noticable delay while it gets switched on again, which for most users is a lot more important than its peak speed anyways. The T5400 (the especially badass one that's not coming out until the summer) gets around this by scaling CPU power and voltage to meet current needs--and it shows.

    Witness their mobile benchmark report [transmeta.com] [note: 116k pdf], based on a new benchmarking methodology they invented (read up on it he re [transmeta.com] [note: 93k pdf]) which:

    1) mirrors actual use--i.e. doesn't run full throttle all the time, which almost never happens under normal use, especially for a notebook

    2) includes metrics for energy efficiency--that is, it reports not just work/time, but work/WattHour and work/time/WattHour.

    For those who don't want to check it out, the result is that across 6 tests (operating system load, system idle, Office 2000, web browsing, mp3 playback, and soft DVD playback) comparing the T5400 to a P3 500, the Crusoe processor was:

    95.3% as fast (yeah, this includes the "system idle" test, which is a bit of a cheap freebie in this category) [note--this is just my straight average of the 6 categories, which is absolutely unmathematically correct, but oh well]

    409.2% as efficient in terms of work/Watt-hour

    395.3% as efficient in terms of work/time/watt-hour.

    All in all, pretty damn impressive. And it's worth noting that it's over 6 times as efficient in the system idle test--which is what your system probably does most anyways.

    Of course, this only measures the power drained by the CPU+NG, and not the screen, HD, etc. But...I have no trouble believing that a CPU that's 4 times as efficient under normal use will give 2 times the overall battery power.

    I gotta go now, but the point of all this rambling is, this chip is pretty damn neat. I'm impressed.
  • by Inoshiro ( 71693 ) on Wednesday January 19, 2000 @03:07PM (#1357367) Homepage
    "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."

    This is like saying that because GM is making cars, they have to follow Ford's lead in how to make them. The x86 ISA is pretty much developed right now, with instructions for anything you'd care to do in silicon (or emulation). Since Intel has said that their next proc is VLIW, it looks like TransMeta's VLIW proc is leading them...

    "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."

    The purpose was never performance, or the masturbatory RISC/CISC debate stuff. Its purpose is to provide good performance for insanely low levels of power consumption.

    "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?"

    I think you are refering to the fact that the translation units can be upgraded via software. Software which comes over the internet :-)

    "However, Linux does not have a standards-conforming browser (i.e. IE) available until Mozilla is complete. "

    (sarcasm in good humour)
    Christ, what've I been running? Jeez, I guess it was just Bill himself pushing a cloaked IE through my net connection onto my desktop, as I can't be running something that's not been released..
    (/sarcasm in good humour)

    This will make a very nice "web panel" device, like the one Cyrix promoters were pushing.. I know I'd love to replace my 486 X terminal with a wireless laptop display :-)
    ---
  • by Anonymous Coward on Wednesday January 19, 2000 @03:18PM (#1357377)
    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...
  • by rogerbo ( 74443 ) on Wednesday January 19, 2000 @03:22PM (#1357384)
    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?
  • by Esperandi ( 87863 ) on Wednesday January 19, 2000 @03:23PM (#1357386)
    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
  • by Ryan Taylor ( 32647 ) on Wednesday January 19, 2000 @03:51PM (#1357401)
    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.

    Mobile Platform Benchmarks (http://www.transmeta.com/crusoe/download/pdf/Benc hmarkWhitePaper_1-18-00.pdf) (.pdf, 93 KB)

    Transmet a Mobile Benchmark Report (http://www.transmeta.com/crusoe/download/pdf/Crus oeBenchmarkReport_1-18-00.pdf) (.pdf, 116 KB)

    Sincerely,

    Ryan Taylor
  • by |DaBuzz| ( 33869 ) on Wednesday January 19, 2000 @04:04PM (#1357403)
    - 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.
  • by ecampbel ( 89842 ) on Wednesday January 19, 2000 @04:16PM (#1357407)
    RISC code is extremely optimized for a specific processor architecture, and optimizing RISC code is a very processor intensive job. Taking highly optimized RISC code (most of the time significantly reorded to exploit parrel and pipelining efficiencies), and trying to generate equivelent instructions in another architecutre would be very slow. The Crusoe architecure is a lot better at taking a few correctly ordered CISC instructions, expanding them to Crusoe's instruction set and highly optomizing them, rather than trying to convert and optomize 8 or 16 out of order optomized RISC instructions.

    If RISC code was indeed easier to emulate, then JAVA would compile to RISC instructions, not CISC bytecodes. It compiles down to CISC bite codes so that the JIT on a particular platform can take one or two bite codes and expand them into the native instruction set of the operating system, and optomize them from there.

    Another reason, there has never been a RISC emulator that has performed at anywhere close to a resonable speed. Any emulation of the Mac done on the PC only handles 68k CISC code. The reason for this is that RISC emulation is just too slow.

    Their emulation tricks will not work on MMX or other instructions nearly so well. Curose can't make up the time it takes to emulate the instruction set by having better hardware. MMX and the G4 vector processing units utilize many of the same tricks that the entire Cursoe processor utilizes such as long word instructions, parallel processing and other optimization techniques. Also, the hardware of these multimedia units are explicitly optimized to process these special instructions. This means emulating these instructions would drastically slow down the chip.
  • by Frac ( 27516 ) on Wednesday January 19, 2000 @04:19PM (#1357409)
    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...

    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.

  • by hpa ( 7948 ) on Wednesday January 19, 2000 @04:34PM (#1357426) Homepage
    Already doing it. It was demoed at the launch.
  • by Chas ( 5144 ) on Wednesday January 19, 2000 @05:07PM (#1357456) Homepage Journal
    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!!!
  • by rob_from_ca ( 118788 ) on Wednesday January 19, 2000 @05:17PM (#1357463) Homepage
    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.
  • ... 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".
  • by ~k.lee ( 36552 ) on Wednesday January 19, 2000 @05:39PM (#1357483) Homepage
    The fact that ecampbel's comments in this thread have been moderated so high is proof positive that when you referee technical opinions by popular vote, you get lousy technical opinions.

    RISC code is extremely optimized for a specific processor architecture, and optimizing RISC code is a very processor intensive job.

    So is optimizing CISC code, or, for that matter, translating CISC code to VLIW and then optimizing the VLIW instructions. In fact, students of compilers and architecture history know perfectly well that optimizing RISC code is actually much easier than optimizing CISC code. One of the prime motivations behind the uniform register file and instruction set of RISC architecture was ease of compilation.

    Taking highly optimized RISC code (most of the time significantly reorded to exploit parrel and pipelining efficiencies), and trying to generate equivelent instructions in another architecutre would be very slow.

    This might have some relevance, except that modern Intel architecture code usually consists of simple, RISC-like operations that are just as idiosyncratically reordered to exploit the pipelining/superscalar efficiencies in modern Intel chips. If translating RISC code is slow, then so is translating modern x86 code. See my other comment [slashdot.org] in this thread.

    If RISC code was indeed easier to emulate, then JAVA would compile to RISC instructions, not CISC bytecodes. It compiles down to CISC bite codes so that the JIT on a particular platform can take one or two bite codes and expand them into the native instruction set of the operating system, and optomize them from there.

    Java, nee Oak, was designed for embedded applications; the original motivation for using CISC-like bytecodes (and a stack architecture, of all things) was code compactness. Ease of translation into native machine code for JITs was not one of the primary concerns when the bytecode format was selected.

    Another reason, there has never been a RISC emulator that has performed at anywhere close to a resonable speed. Any emulation of the Mac done on the PC only handles 68k CISC code. The reason for this is that RISC emulation is just too slow.

    No; the reason is the lack of market demand. The x86 architecture's relative poverty of registers, and their nonuniformity, make it rather difficult to emulate, say, PowerPC code efficiently, but adequate performance could probably be achieved.

    ~k.lee
  • by GC ( 19160 ) <giles@coochey.net> on Thursday January 20, 2000 @01:08AM (#1357653)

    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!

You have a tendency to feel you are superior to most computers.

Working...