Slashdot Mirror
Transmeta Unveils 256-bit Microprocessor Plans
nam37 writes "PCWorld has an article about how Transmeta has outlined its initial plans for a new 256-bit microprocessor dubed the TM8000. They claim it will offer significant advantages over their current TM5x00 line of chips. The processor will be a switch to a 256-bit VLIW (very long instruction word), allowing twice as many instructions in one clock cycle and greater energy efficiency." The article also touches on the popularity Transmeta enjoys in Japan, noting that 92% (CD: corrected from 55%) of the company's revenue comes from there.
This is the size of the INSTRUCTION which is encoded, not the datapath.
.12 uM, and shove it out the door. Remember, if you shrink the processor power to 0, everything ELSE still burns alot: screen, drive, I/O, even in an ultrasmall notebook.
Unfortunatly, transmeta is hampered by several factors.
The first is that 256b will require the translator to discover 8 translated instructions (assuming a 32b instruction size) which can be executed in parallel to get good performance. This is a TOUGH barrier, the reality is probably closer to 2-4. Also, the way to get more instructions to issue is through speculation, but too much speculation really hurts power.
Secondly, the transmeta cache for translations and translating code is so small that it hurts quality. Transmeta would do better with OS cooperation, giving a larger hunk of memory to store more and better translations, and to enable more sophisticated translating algorithms. But that breaks the x86 compatability model.
Third, they have lost the battle on performance, and power doesn't matter: Intel can outfab them and if REALLY low power was required/useful in the x86 world, Intel could crush them by simply dusting off the old Pentium core, process shrinking it to
Fourth, transmetas claims in the past have been so full of hot air, so why should we believe anything they say now?
Test your net with Netalyzr
> First there was that 4-bit microprocessor, then it went to 8-bit, then 16-bit, 32-bit, and 64-bit.
No one should ever need more than 640 bits.
Sheesh, evil *and* a jerk. -- Jade
Transmeta chips are VLIW and therefore the bit width they are referring to is not width of the data bus, but the number of instructions that can be executed simultaneously. At present the transmeta chips are 128-bit (four 32-bit instructions), and the new ones will be 256-bit (eight).
Since transmeta chips are VLIW, they do not have to schedule instructions, and do not have to determine (at run time) which instructions can be executed in parallel. With VLIW, both of those functions are performed by _software_, statically, all at once. A singificant amount of the complexity of a cpu is dedicated to performing these functions, which are offloaded to software by transmeta in their "code morph" phase.
Furthermore, the conversion from outdated x86 microOps occurs in software during the "code morph" phase, further offloading functionality that otherwise would exist in silicon.
For these reasons, the transmeta CPU is dramatically simpler than comparable x86 cpus. Unfortunately, it did not perform as anticipated. However, since the die size is so small and the cpu so simple, it does offer some advantages (low power consumption, low heat dissipation).
Since you're the first person I've read tonight that is confused AND honest about being confused, I'm happy to take a stab at answering some of your questions. I am not a Crusoe expert, and my field isn't microprocessors. Just a warning.
1) What's a "true" 1024 bit processor?
You have to make assumptions to answer this question. Probably the most useful "bit"ness to know for a particular processor is the number of bits it can use for a "normal" memory address. For Athlons, that is 32 bits, and the same for the Intel P4. Some Intel chips have a 4 bit extension, but it's a pain to use and should be ignored (and mostly is). There are a handful of mass produced cpus with 64 bit addressing; the DEC^H^H^HCompaq^H^H^HIntel Alpha, some version of the Sparc lineup, and certain varieties of IBM's POWER family come to mind. Since memory addresses on typical cpus refers to one byte, having 32 bit addresses allows you to uniquely reference 2^32 (~= 4 billion) bytes with a single memory address. How much of that "address space" you can map to physical ram is an entirely different issue. Being "64 bit" typically also means you can represent every integer between 0 and 2^64-1 exactly.
In my experience (I do scientific computing, not enterprise stuff), the ability to address tons of ram from a single cpu is what really counts 99.99% of the time. We have a machine, a Compaq ES40 Model II, with 1 cpu and 14GB of ram. It can grow to 32GB of ram -- and the new version goes up to 64GB of ram (and the machine's a steal at $20K with educational discount -- I'm being serious, but things will change with AMD's 64bit x86 "Hammer" stuff at the end of this year). You can't do that in any sensible way on a 32 bit cpu.
2) From what I understand from the other posts, this transmeta proc is not 256 bits in the same sense that Intel's current chips are 32 bits
True. The "instruction word" on most modern (RISC) cpus == "word" size == integer size == memory address size. In fact, this was one of the big simplifications propounded in the RISC paradigm. Note that modern x86 cpus are RISC based, even though their instruction set is CISC (you can look up CISC and RISC and the web; note that CISC was the right thing to do under certain conditions). The Transmeta Crusoe is *not* a RISC cpu. In some ways it is simpler. However, it requires *very complicated* software support, unlike RISC cpus (take this with a grain of salt). So when someone says that the Crusoe instruction word is 256 bits, you shouldn't make any assumptions about integer or memory address sizes (I don't know, but I assume these are 32 bits on the Crusoe -- 64 bit would be silly for the Crusoe's target applications). A single "instruction" for a Crusoe will (evidently) be 256 bits in the future. However, it will (evidently) be guaranteed that this 256 bits will be broken down into 8 smaller 32 bit instructions by the cpu. That is, 256 bits are fetched from memory (don't ask which memory) at once, which the cpu will interpret as 8 different things to do at the same time.
I'm not mentioning a lot of stuff, like variable width instruction encoding in the x86 instruction set, or how software converts files full of x86 instructions into files full of 256 bit Crusoe instructions, and certain efficiencies and inefficiencies of 64 bit cpus versus 32 bit cpus. My main point is that you shouldn't get hung up on the "bit"ness of a cpu unless you are writing software for that cpu. FWIW, 64 bit cpus is nothing new. I talked to a 70 year-old who claimed to work on experimental 64 bit machines in the 1960s or 70s for the military (I don't recall which military =-).
Since 2^64 is a *really* big number (where are those stupid "number of atoms in the universe" figures when you need them?), it's unlikely that we'll need memory spaces larger than 2^64 anytime soon. Same goes for integer sizes. Improved floating point precision from wider floating point types would be much appreciated by folks like me who are tired of working with crappy 64 bit doubles and can't afford to take the performance hit of wider fp types on 32 bit architectures.
As far as optimal width for instructions, I have no idea. If you want to make a big fat instruction, you better have a lot of good stuff to do at once. And that depends not only on the compiler that converts C (or whatever) into the cpu's instruction set, but also how the human chose to use C (or whatever) to implement her idea.
Computer history is full of people wanting to do something, computers catching up by removing performance bottlenecks, humans adjusting to the new machines, and then the whole thing repeats. Heck, at one time it wasn't clear whether digital computers were really a better idea than analog computers (however, I think this argument is over for general purpose computing), and analog computers don't have any "bits" at all.
Like I said, don't take anything I wrote above (at 5am while waiting for some code to produce output) as fact without double checking somewhere else. If you really want to get your head screwed on right, take an architecture course or (if you're really disciplined) work your way through something like Hennessy and Patterson's "Computer Architecture, A Quantitative Approach". You can get a lot of good info from 'popular' texts like "The Indispensable PC Hardware Book". A big warning about that book, though -- when the author writes "PC", he almost always means "PC when used with MS-DOS or Windows" -- often this is subtle, for instance when discussing the boot process or how memory is organized.
-Paul Komarek