Slashdot Mirror
Transmeta To Release Next Generation CPU
CodeShark writes: "According to this story at CNN, Transmeta is set to release their new TM6000 microprocessor this afternoon. The chip apparently incorporates some of the functions usually provided by high-performance (and high price!) chip sets. Transmeta is reporting a further reduction in power requirements by 44% and sees the laptop and sub-laptop markert as the primary markets for their new CPU. Intel and AMD claim to be catching up with the Transmeta chips in terms of power requirements, I'd be curious to find out what the real world comparisons might make of those claims ..." If anyone out there is at Microprocessor Forum, please say in comments any further details that are made clear there.
Here's the press release from transmeta.
Enjoy.
From what I've noticed, crusoe chips really only show their worth in the smaller sub-notbooks, like the sony picture book, where there isn't room for a cdrom or floppy drive. They also don't have the heat/fire problems that have cursed many laptop manufacturers. I have an old gateway laptop that after 20-30 minutes of use gets too hot to keep on my lap.
The battery life of a laptop also depends on the display (the brightness, size and type), how long the hard drive stays spinning, how much you use the removable drives (ie: CD-ROM, DVD-ROM) and any other components that are active.
Transmeta's claims have been shot down several times because Transmeta doesn't have control over the power consumptions of the parts outside of the processor and the chipset.
It's also worth noting that your Celeron doesn't have the benefit of Intel's speedstep technology, and wastes power running at 700 MHz all the time. Secondly it's not part of the lower voltage line of P III M chips. Just one of those things.
--Jimmy has fancy plans; and pants to match.
These products would include things like Tablet PCs and wearable computers, ultra-dense servers, networking equipment, printers and set-top boxes, he said.
"As people want to go and include things like wireless technology in these things, where do you put the wireless chip? There wasn't any room left on the board," Ditzel said.
The only reason to use x86 is because you want to use Windows (non-CE, if you want to use that ARM is of course the only way to go).
Transmeta chips are only low on power consumption compared to other chips running x86 code, compared to other chips performing the same tasks they are definetely not.
The only truly viable markets for their code morphing are (sub-)notebooks running Windows, ironic with the Linus connection, and as a transition path for anyone who would want to make a dent in the desktop/server market (you could introduce a new architecture and still get very passable performance on x86, a lot better than Merced etc in any case).
From $1.19 to $2.25.
As mentioned on MacCentral IBM just released some PowerPC G3 bundling all their recent breakthroughs and going up to 1 GHz.
"SOI and SiLK taken together with IBM's smallest 0.13-micron copper manufacturing process has resulted in a processor that typically dissipates 3.6W of power at 800MHz [...]"
HP actually found that some code actually ran faster in their PA-RISC emulator for PA-RISC than on the bare hardware! Perhapse HP was using the equivalent of gcc -O instead of gcc -O2 in their trials, thus giving more room for dynamic optimizations, but they got good results for an early project. Dynamic code optimization still looks promising. HP is working on a product utilizing quick-and-dirty PA-RISC to IA-64 translation and dynamic code optimization to ease the transition from PA-RISC to IA-64.
The HP Dynamo project has some good arguments about why dynamic optimizations might be becomming increasingly usefull. Basically, HP was researching emmulation, so they wrote a PA-RISC emulator to run on PA-RISC and put in some dynamic code optimization to increase performance of commonly run code. There's the old rule of thumb that 80% of your CPU time is spent on 20% of the code, so they concentrate expensive optimizations on the commonly run code, after on-the fly profiling indicates which areas should be optimized. It's like having a -O4 option for gcc and only using it on the code that gets run alot, in order to avoid all the bloat associated with gcc -O3.
Personally, I'd love to see AMD or Intell throw away hardware emulation of the ancient x86 instruction set. The greatly restricted number of registers causes the compilers to really hide the inherent parallelism in the source code. A lot of chip realestate is wasted in extracting the parallelism back out of the binaries. It's not as bad as the stack-based JVM, but the x86 instruction set is pretty bad about expressing parallelism in the source code. I think software emulation of legacy apps is where it's at. If Intel or AMD released an x86 emulator for thier new chipsets and got Microsoft to go along with the idea of software emulation of x86, then we'd see native apps running much more efficiently. It's my understanding that IA-64 kind-of does this with an x86 emulation mode. However, I think that chip realestate would be better spent on thins to speed up native code.
If I'm not mistaken, Win95 even had partial virtual DOS machines for each DOS executable. It's not too much more of a leap to emulate the ancient instruction set after you're emulating the ancient OS. Transmetta wants the flexability to completely redesign the native instruction set for each release, and that's understandable. However, it would be nice to move on to compiling into something that better expresses inherent parallelism in the source code.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
What seems strange to me is that the Crusoe is x86 ISA compatible. THis must mean it's doing all the VLIW instruction packing on the fly. My guess is that's not gonna fly, ehhe. What's VLIW buying you in this case?
A bunch of things. Primarily, the heat and power loss associated with the hardware decoding logic implementation does not happen since this is implemented in software. Second, ignoring optimizations, the decoding only really needs to happen once.
Finally, being in software allows for really complex decoding logic (such as trying execution based on radical assumptions, failing, and retrying immediately without those assumptions) to be implemented much easier, and also allows for that logic to be updated easily in the case of a mistake.
...will these Transmeta chips follow the same 'faster, hotter, more expensive' trend that AMD is following?
AMD's latest CPUs use less power and generate less heat. When they get to 0.13 micron with silicon-on-insulator and copper interconnects (Q1 next year), AMD chips will use 20% less power and run 20% cooler.
Personally, I preferred Zmodem.
It's 2:30 am and I can't sleep, so this is probably going to sound incoherent.
The translation to micro-ops isn't nearly as complicated as Transmeta's code-morphing, mainly becuase it's about taking more complicated instructions and breaking them into simple, manageable pieces that can be chained very quickly.
Most of these functions are memory addressing functions. array_pointer+(item_number*item_size) can be addressed very quickly, but is multiple micro-ops in itself, not to mention the actual function that it is to accomplish.
It's also one of the things limiting the superscalarness of P6-based chips, which can handle Four micro-ops in the first instruction, and the other two instructions that cycle must be only one micro-op. I think Athlons are not bound by this limitation, however.
Code-morphing is more taking the code, converting it to a new instruction set, and then keeping that code around. Transmeta throws in some nifty optimization gizmos, too. It also _saves_ this information, which is usually much larger space-wise than the original instructions, but is still quite nice.
Essentially, it's an optimizing emulator in hardware. Old idea, new hardware.