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.

Comments

Not 55% revenue from Japan - its 92%

[Utopia]

92 percent of Transmeta's net revenue came from Japan, a figure which is up from 55 percent in the year earlier.

Re:Not 55% revenue from Japan - its 92%

[CrystalFalcon]

I hope everybody realizes that this number says absolutely nothing about the health of the company, just where its current customers are.

Generally it has me a bit worried - being so dependent on Japanese customers is not a perfect state of the union for a Californian company...

Re:Not 55% revenue from Japan - its 92%

[larry bagina]

but 92% of 0 == 55% of 0, so there's no difference.

"makes no predictions on availability date"

[blumpy]

Who knows when this will be available... could be years, this might just be a way to boost stock value temporarily without consequence for several years.

Re:"makes no predictions on availability date"

[SHEENmaster]

It doesn't matter when it is released, there will already be a NetBSD port. Flame Entertainment

55% figure is wrong

[Geek Boy]

From the article:

In the first quarter of the current fiscal year, 92 percent of Transmeta's net revenue came from Japan, a figure which is up from 55 percent in the year earlier.

In other words, in the first quarter, 92% of their revenue was from Japan. Last year during the first quarter, 55% of their revenue was from Japan.

That could mean anything, btw.

Re:55% figure is wrong

[susano_otter]

That could mean anything, btw.

Wait, wait! I know this one! I saw it in a movie once: The Japanese are stealing our technology!

Re:55% figure is wrong

[Physics Dude]

"In other words, in the first quarter, 92% of their revenue was from Japan. Last year during the first quarter, 55% of their revenue was from Japan. That could mean anything, btw."

What are you talking about?

Are you claiming that they didn't receive 55% of their revenue from Japan in the first quarter of last year?

Their statement means exactly what it says! It shows that a larger percentage of their revenues are coming from Japan than a year ago.

Don't drink and post. :)

Re:55% figure is wrong

[Geek Boy]

Are these factors adjusted for currency fluctuations? Inflation? Economic instability? I could go on but it's not worth it. There are countless things to consider still. This is headline news, not in-depth analysis.

How will this chip be energy efficient?

[JebusIsLord]

Could someone please explain to me how you can make an energy efficient comparitively simple chip with 256-bit data paths? I thought increasing the bits made chips much more complex, which kind of goes against exactly what Transmeta has been all about up until now. Please explain to me as I assume they know what they are doing.

Re:How will this chip be energy efficient?

[NanoGator]

I'm curious about this as well. Is this the type of thing that could make people forget about Itanium, or is this case where an insane # of bits means it's not practical for anything useful?

Re:How will this chip be energy efficient?

[ipsuid]

Unlike an Intel processor, the Transmeta chip is based on a RISC architecture. If you take a look at a CISC processor, like an Intel chip, there is a ton of work that just goes into decoding the instructions. Some instructions are one byte, others are two, some have data imbedded in various bits of the instruction, etc. This makes the decoding and dispatching of instructions quite complex. On a RISC architecture chip, certain bits always indicate the instruction, others are always data. Decoding on these chips is simple.

Now, if you were to double the number of input bits on a CISC processor - you would have to duplicated some fairly complex (read power hungry) circuitry. On a RISC processor, doubling the input bits simply doubles some simple hardware.

Still, that doesn't explain why 2x the bits yields an energy saving... The reason for that is that the concept of doubling the circuitry is a simplified explanation - some of the hardware can be shared. Really, they're just going to be feeding two instructions through in parallel, so for example, you only need to go through one power hungry bus cycle to get the data. You only need to run the dispatch unit once per two instructions, etc.

Much like an automated car wash that uses a bunch of water and electricity. If you changed the design slightly, so that you could run two cars through at once instead of only one you'll use more water and electricity then one car but not as much' as if the two ran through seperately.

Re:How will this chip be energy efficient?

[ender81b]

And while you're at it would someone kindly explain why 256bit would only double the efficiency over current (64bit) chips? SHould it quadruple? One last question, since the article was mighty skimpy on details, why doesn't Intel/Sun/Amd/etc make a processor > 64 bit?

I am assuming that their are a ton of technical challenges to overcome, as well as the fact that such chips probably couldn't run at very high clock speeds. Any other reasons?

Re:How will this chip be energy efficient?

[edrugtrader]

its actually very simple... you just say you are going to make it, then don't.

then enjoy all the publicity and sell more of your simple 8 bit processors.

Re:How will this chip be energy efficient?

[squidinkcalligraphy]

AFAIK, the itanium processor is essentially a RISC architecture.

Re:How will this chip be energy efficient?

[Anonymous Coward]

Excellent!

Re:How will this chip be energy efficient?

[GenCuster]

The tranmeta chip was 128 bit.

Re:How will this chip be energy efficient?

[Ami Ganguli]

I think the current Transmeta chips are 128 bit.

"Conventional" CPUs (like Intel/Sun/AMD/etc) wouldn't benefit from 128 bits, but the Transmeta chips are VLIW, meaning they cram several instructions into a single word. Doubling the number of bits doubles the number of instructions that can be crammed into a single word. Of course this assumes that you can extract that level of parrallelism from the code.

Re:How will this chip be energy efficient?

[InfiniteWisdom]

"I think it would be a good idea" Ghandi, on Western Civilisation

Its spelt GANDHI, btw.

Re:How will this chip be energy efficient?

[panurge]

There is a big difference between a VLIW processor and a CISC processor. VLIW is basically a way of carrying out processing more efficiently than CISC, trading off instruction word length and a kind of nanocompiler which works out how to rearrange instructions (and uses a cache of external memory for the rescheduled instructions, btw) for complex decoding hardware and logic for identifying register and pipeline status. So a 256 bit VLIW processor is in no way comparable to a 256 bit CISC processor.
In fact, I seem to recall that the original VLIW work in the 80s was done on 512 bit and 1024 bit designs, using bit slice components of course.

Large processors need large data and address buses, which means a lot of power hungry transistors on the periphery of the chip, as well as the longer array of the various bus gates inside the chip. The technical challenges in doubling the bus width are enormous.

In fact, a major feature of the Transmeta design is the way the internal compiler reviews code, rearranges it and caches the streamlined code for repeat execution. It means that, just like JIT compilation in Java, the first time through a loop is slower than subsequent accesses. The wider the instruction word, the greater the opportunity for this kind of rescheduling, but also the more cache memory is needed and the more the initial performance hit. Great for playing DVDs or database searches, not so good for office work.

Re:How will this chip be energy efficient?

[taniwha]

I think they are referint to 256 bit INSTRUCTIONS - it's a VLIW after all and they want to be able to issue as many ops per clock as possible.

Given that TM's JIT-recoding to VLIW's been around for a while i guess they know by now if they can get usefull ILP out of such a wide instruction word.

Their approach to low power - basicly gating every clock in sight even though it plays havoc with the tools most other people use is becoming more common (and the tools are evolving too). It works because they only turn on the parts of the chip that are being used at anyone time and a very small granularity - in the past people like Intel tend to do things like stopclk duty cycle modulation (stops the clock to everything for some percentage of the time) - this still means you're wasting energy when you are running

Re:How will this chip be energy efficient?

[loony]

> Could someone please explain to me how you can make an energy efficient comparitively simple chip with 256-bit data paths?

Its 256 bit instructions not data paths... so the basic idea is you do (in theory) twice as much per instruction, so to get the same work done you can run at half the clock speed - thats where the reduction in power comes from... They'll surely not do that, they will keep the clock speed high but gain performance without having to use too much more power.

Re:How will this chip be energy efficient?

[cartman]

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

Re:How will this chip be energy efficient?

[ender81b]

Wouldn't this type of processor type carry a huge hit if like a JUMP command or something to interupt the pipeline was encountered? I remember hearing this was a big problem in Pentium chips with it's long pipeline stages - it would have to be worse in a system like this... unless the compiler/branch prediction is really, really good I suppose.

Re:How will this chip be energy efficient?

[Anonymous Coward]

I thought it was VLIW, as is the new Crusoe chip, which from what I've read, makes it different from both RISC and CISC.

Re:How will this chip be energy efficient?

[Anonymous Coward]

256 bit instructions on a 128 bit datapath? I wonder which is more efficient: splitting 256 bit instructions into two to fit them on the datapath (basically a state machine, or what RISC is going away from) or doubling the size of the datapath.

Re:How will this chip be energy efficient?

[ipsuid]

VLIW is just describing the structure of the actual instructions. Making instructions all the same size, with the same structure is a RISC concept. It is true that many current CISC chips have a RISC core... The pentium's for example run at 128bit internally (if I'm remembering correctly). Of course - there's too much hype about more bits better... just look at game consoles in the 90's: 8bit, 16bit, 64bit... Funny how the neo geo's are still around ;-)

Re:How will this chip be energy efficient?

[sjnokker]

The reason for that is that the concept of doubling the circuitry is a simplified explanation - some of the hardware can be shared. Really, they're just going to be feeding two instructions through in parallel, so for example, you only need to go through one power hungry bus cycle to get the data. You only need to run the dispatch unit once per two instructions, etc.

So is this trick repeatable? I mean, if you would not double but quadruple the bits, would this mean even more energy savings?

Mark.

Re:How will this chip be energy efficient?

[Anonymous Coward]

It's spelled "It's spelled", btw.

Cudos on getting 50% of the words wrong in a post bitching about someone's spelling.

Re:How will this chip be energy efficient?

[Kindaian]

It is very complex but from what i grasp, by using very complex instructions, you archieve multiple simultaneous tasks with unrelated data easly. With other platforms, to do that, you must allow for the processor to do the thinking of that and coach the internal instructions to flow the correct way.

The chip design can be thrus much simpler. On the other hand, by using a code-morph as it's "public" layer, the chip can be adapted to almost any requirement, making it very popular for... yes... making gadgets... and that is life and blood in Japan.

[how i liked to have a devkit for transmeta... but here in Europe, that is not only hard to find, but not a *must* for this market]

Cheers...

P.S.- Can someone pls add a JVM inside the new transmeta processor? Why run x86 when you can run bytecode directly?

Re:How will this chip be energy efficient?

[Beliskner]

WHOA! Intel would never do this as it increases IPC, so Transmeta either have to decrease their MHz or drum into the public somehow that "MHz has nothing to do with performance". In other words Transmeta advertising vs. Intel advertising. Obviously Transmeta will fail unless they debase their packaging by hiding the MHz like AMD by showing something like Athlon 1500+ e.g. Crusoe 800+, or some crazy marketing like Crusoe 400x2+, or maybe kick-ass Crusoe 400TwinTurbo

Intel has made GHz cool and increasing IPC uncool. Transmeta is trying to blow this away. If they are succesful, Intel's marketing hype will unravel and the company will consume itself like Jabba the Hut with a banquet just out of arms reach (Jabba is immobile methinks).

Or maybe killing Intel's marketing will just cause MSOffice+email people to be happy with their PCs instead of constantly upgrading when Intel tells them to, resulting in a crash in the tech sector. Correction: been there, done that.

Re:How will this chip be energy efficient?

[Anonymous Coward]

http://www.dictionary.com/search?q=spelt

"spelled" sounds like something a four year old would say.

Re:How will this chip be energy efficient?

[Anonymous Coward]

IIRC Transmeta uses the 256 bit path to do several 32-bit x86 operations. So they double the amount of work / clockcycle. It's much better than doubling the frequency since the energy use rises exponentially.

Transmeta already has a risc-like datapath so just making it wider doesn't increase complexity that much.

Re:How will this chip be energy efficient?

[John Sullivan]

Cudos on getting 50% of the words wrong in a post bitching about someone's spelling.

"kudos"

Re:How will this chip be energy efficient?

[John Sullivan]

So is this trick repeatable? I mean, if you would not double but quadruple the bits, would this mean even more energy savings?

Quite possibly, but eventually you get into the law of diminishing returns. The engineering effort required to design something twice as complicated, and make sure it actually works, together with the increased cost in silicon real-estate may make it difficult or uneconomical to increase the complexity beyond a certain limit. At least for the current generation.

Re:How will this chip be energy efficient?

[p3d0]

Not taking any chances, huh? :-)

Re:How will this chip be energy efficient?

[p3d0]

Um, while you're at dictionary.com...

http://www.dictionary.com/search?q=spelled

Re:How will this chip be energy efficient?

[Anonymous Coward]

That depends on the pipeline - longer the pipe, the bigger the hit when you get the wrong thing in the pipe. As far as I know the P4 has the longest pipe out there. The difference is that this chip is a RISC archetecture. With RISC it's a lot easier to run many pipelines in parralel, and generally you're pipe doesn't need to be all that long. Actually I'd say it's probably better to have a shorter pipe with RISC since it gets harder to organize with a lot of long multiple pipes. But I don't really know since those guys are a lot smarter than me and might have all that figured out.

Re:How will this chip be energy efficient?

[Anonymous Coward]

VLIW is not RISC. It's its own thing.

Re:How will this chip be energy efficient?

[Anonymous Coward]

My Guess: Lesser clock speed + VLIW = lower power.

Re:How will this chip be energy efficient?

[stevew]

This is basically completely wrong.

The Transmeta machine is a VLIW machine, almost the antipathy of CISC. It is closer to what is called "superscalar" machines than anything else.

The idea is that you have a 256 bit INSTRUCTION, not data path. There are several different functional units. Maybe one is a multiplier/divider, another is a floating point unit, another is an address calculator. Maybe you double up each of these resources when you go from 128 to 256 bits. The idea is that each functional unit gets it's own part of the instruction. VLIW stands for Very Large Instruction Word after all - not very large data path!

Next - you need fancy compilers, in this case it's the Transmeta just-in-time compilation that can schedule use of as many as possible of these functional units on a computation thread. Thus as the number of functional units goes up, the potential computation done per clock goes up.

Re:How will this chip be energy efficient?

[stevew]

Just for the record - the Cydra 5 was 128 bits. I know, I helped wire up every one of those registers ;-)

The Trace architecture was extensible to 256 if memory serves.

Both machines were available in the mid 80's.

The fact that you couldn't grow these architectures and remain binary compatible was there achiles heel - consequently they were dead -ends both architecturally and commercially. It's the JIT application the problem that is revolutionary.

Re:How will this chip be energy efficient?

[soundsop]

Sorry. You are absolutely wrong about Intel architectures. Although the instruction set is CISC the internal architecture of anything after the original Pentium is decidedly RISC. Almost all high-performance CPUs of the 90's have internal RISC architectures (Intel, AMD, Alpha, Sparc, MIPS).

The Intel chips have a mapping stage that maps CISC instructions to multiple internal RISC instructions (what they call microcoded instructions).

It's reassuring to see that Slashdot's advanced moderation system promoted a techically incorrect posting to a score of 5!!!

Re:How will this chip be energy efficient?

[deepchasm]

Transmeta either have to decrease their MHz or drum into the public somehow that "MHz has nothing to do with performance".

Not really. Certainly, at the moment, Transmeta doesn't really compete directly with Intel for the home computer market. They specifically market with regard to the Crusoe's very low power consumption. This isn't likely to matter very much to the home user, but in large server farms where monthly power costs matter, or in dedicated hosting facilities where your power consumption per rack is limited, Transmeta processors make a difference.

Note that although the Crusoe does compete well with Intel type technology when compared processor for processor, the difference when power consumption is compared is staggering!

Re:How will this chip be energy efficient?

[flatrock]

Here's what I don't understand. VILW uses a large set of complex instructions. Those instructions contain multiple opperations that can be performed in parallel by the processor. They can't just pack in any group of operations into an instruction word if they want them to be handled efficiently. It's up to the compiler to create machine code that breaks down the program into these complex instructions that the processor can handle in an optimal way.

My confusion comes from the fact that the Crusoe is rarely dealing with code that was compiled for it. The code is usually compiled for X86, and then "code morphed" into instructions for the Crusoe. That seems like you'd lose all your efficiency because even if the compiler takes a long time to figure out the best instructions, it's time taken once and not while the application is running. Code morphing is interpreting the x86 into Crusoe instructions and then running them on the Crusoe, and the code morphing is done while the applicatin is running and on the same processor. I just don't understand how this can be efficient.

Is the current X86 processors which take CISC instructions, convert them into a reduced set of instructions that it can handle quickly, and then shove them through at really high clock speeds equally inneficient that a horribly non optimized VILW processor can compete? If that's the case, why isn't the Itanium which is VILW blowing us away with it's performance?

Re:How will this chip be energy efficient?

[Jobe_br]

unless the compiler/branch prediction is really, really good I suppose

I think this is kind of the point ... the complexity/intelligence of branch prediction that is achievable in hardware (while quite amazing in and of itself, when you get right down to it), pales in comparison with what can be done by Transmeta's code-morphing *software* ...

As with anything, though, their are various opinions on this - is it better to do certain tasks in software or in hardware ... only time will tell, now that we have systems that take advantage of each of these approaches.

Re:How will this chip be energy efficient?

[Jobe_br]

"... or drum into the public somehow that "MHz has nothing to do with performance ..."

Its a slow process, but with both Apple and AMD trying hard to educate consumers, in time, a new "benchmark" of a computer system's speed will be used ... its just a matter of time, in my opinion.

Not to mention that eventually, as Intel's processors change architecturally (e.g. Itanium, McKinley), they themselves will have to educate consumers that an 800MHz Itanium processor can be faster than a 2.4GHz Pentium 4 (I'm not sure under what circumstances, having no direct experience with either processor, but certainly there is some benefit to Itanium, right?!? :)).

If you look at Itanium at 800MHz and compare it to say a G4 (or G5 when it debuts) running at 1GHz, or one of AMD's Hammers running at who knows what speed, what will this say about the "MHz Myth"??

Re:How will this chip be energy efficient?

[shess]

The Transmeta machine is a VLIW machine, almost the antipathy of CISC.

Inigo: You keep using that word. I do not think it means what you think it means.

Re:How will this chip be energy efficient?

[Beliskner]

as Intel's processors change architecturally (e.g. Itanium, McKinley), they themselves will have to educate consumers that an 800MHz Itanium processor can be faster than a 2.4GHz Pentium 4

HAHAHAHA HAAAAA!!!! So Intel's advertising department is going to have to undo the advertising done by... Intel's advertising department ha ha haaaaa! Then again this is a good way to get funding in this downturn, here we've got HR emailing themselves to look busy.

Unfortunately I think it's going to be a long time before we see Itaniums replacing the P4 as Joe sixpack's standard comb-puter.

Re:How will this chip be energy efficient?

[cartman]

The whole strategy hasn't worked out that well. Neither transmeta nor itanium blow anyone away with their performance.

Re:How will this chip be energy efficient?

[Jobe_br]

Very true, it will be a while ... but, eventually ... :)

Re:How will this chip be energy efficient?

[dakoda]

everyone knows how pentiums etc are RISC at the core level. However, anyone who knows ans x86 asm will know that the interface to it was and still is CISC. the decoding/translation stages all you CISC->RISC people get all worked up about is rather amusing, as it means completely jack to anyone developing for the cpu (unless they tell you how to manipulate the translator with undocumented instructions or something).

Again, no matter how intelligent and efficnet the CISC->RISC decoder is, i doubt it's anything close to just using RISC. fewer transistors for decode/translate logic saves more power/space for actual computations or cache.

unless RISC cpu's really translate RISC opcodes into some other sub-risc instruction set. that might be implimented, i wouldn't know off hand.

Re:How will this chip be energy efficient?

[karlm]

Fisrt of all, VLIW instructions aren't complex. They're a bunch of RISC instructions taken together as a block. You could make a non-supersclar RISC CPU to run the TM8000 instructions, it'd just take *almost* 8x as long. (It's hard to find 8-way parallelism. I think superscalar x86 CPUs pretty much max out at an average of 2.5 way parallelism. Maybe the TM8000 is using SMT to run two threads on the same chip. Maybe tehy dedicate one of the threads to code-morphing and runtime optimizations)

It does hurt them that they code morph on the same chip that they run the x86 software on. However, they can get away with it becuase they can cache the translated code segments. Self-modifying code and stuff with "debugger bombs" in it may destroy performance and/or prevent proper execution. In general, though, they get saved because, on average, 90% of the time is spent in 10% of the code. This means their translation cache gives them a huge performance boost in most applications. The P4 also uses an on-chip microOp translation cache, probably creating huge savings in terms of power usage due to the x86 decoder unit.

In it's purest form, VLIW would be like taking several MIPS chips and giving them the same cache and register file and demuxing the instructions out to the different chips. The chips would trust the compiler and not check for data dependancies.

Itanium doesn't know what it wants to be. Intel doesn't call ia64 VLIW, they call it "EPIC : Explicitly Parallel Instruction Computing". It's a beast with lots of registers (RE: really long context switches. The ia64 Linux porters decided to cut down on the number of user-space avalable registers in order to shorten context switches.) and register windowing (windowing didn't help SPARC very much, and eats up a fair number of transistors). On the other had, they neglected to give it a full floating point unit, so any floating point op causes an FPSWA (floating point software assist) interupt. Furthermore, the decided not to match the instructions to the bare hardware, but instead made the CPU pretend to hav infinately many execution units and inserted some flags in the instructions to indicate where the parallelism breaks. This is needlessly complex. Don't ofrget on-chip slow-ass x86 emulation. Do a google search for Elburus, or look backa couple of days on /. They've gotsome good arguments about why EPIC (and Itanium, in particular) is worse than VLIW. They also say their approach is better than the Transmetta approach, but say Transmetta is onthe right track. Basically, they would like to see a partiall static and partialy dynamic recompilation solution rather than an all-dynamic solution used by Transmetta. I think the Elburus approach is better for geeks, but may be hard to make seamless for the general populace.

Re:How will this chip be energy efficient?

[taniwha]

IPC vs. MHz in Transmeta's world view is even more confusing - remember they are recompiling x86 instructions into their own native ones (somewhat) on the fly, assuming their code is doing good stuff (and I guess they are if they think it's worth upping the VLIW instruction size for future chips) - so an x86 instruction is being broken down into 1-3 micro-ops which are being packed spread over several 256-bit vliw instructions ....

Re:How will this chip be energy efficient?

[Anonymous Coward]

"I think it would be a good idea" -- Bush, on Indian (and Pakistani) Civilization.

Re:How will this chip be energy efficient?

[soundsop]

everyone knows how pentiums etc are RISC at the core level

Apparently not. The original post got it wrong.

it means completely jack to anyone developing for the cpu

First, this article is about the Transmeta architecture not the interface, so your point is moot. Second, compiler writers target the CPU, and I can guarantee you that they are very interested in the actual internal architecture, in addition to the interface, so your point is wrong. (Although not directly exposing architectural features, like delayed branches in the Sparc, is a good idea.)

no matter how intelligent and efficnet the CISC->RISC decoder is, i doubt it's anything close to just using RISC. fewer transistors for decode/translate logic saves more power/space

Even though a CISC-to-RISC decoder may consume more power/area, there may be a power savings in the external and internal instruction path due to a potentially denser instruction encoding. As with most architectural issues, this is a non-trivial trade-off that requires careful analysis. Of course, Intel doesn't have much choice since they've have been commited (until IA64) to backward compatibility.

Re:How will this chip be energy efficient?

[ipsuid]

OK, this thread has turned into a complete joke. First - I would like to tell everyone to go take a course in reading comprehension. Obviously with more then one acronym per post everyone gets confused. ;-)

Now, having said that:

• I know that VLIW means very long instruction word, not data path
• I know that Intel processors are based on a RISC like core - I'm not talking about execution, I'm talking about decoding,scheduling,dispatch, and issue.
• Anything that does more then one operation at a time is superscalar.

RISC (Reduced Instruction Set Computing) and CISC (Complex Instruction Set Computing) are distinctly different methods of CPU design. VLIW (Very Long Instruction Word) computers use multiple RISC like instructions packed into each VLIW instruction word. The sub-instructions are called atoms; the packed together instructions are called molecules. The point of doing this is to get rid of the decoding/scheduling/dispatch circuitry, since the compiler already pairs atoms together that can run in parallel. The atoms are always occupying the same bits, and are all of the same form... That is what RISC like means folks. The only difference between a RISC processor and a VLIW processor is that the RISC processor still has to pair instructions together as it gets them. The pairing of VLIW atoms has already been accomplished by the compiler.

Go read. Then reply.

Re:How will this chip be energy efficient?

[Beliskner]

an x86 instruction is being broken down into 1-3 micro-ops which are being packed spread over several 256-bit vliw instructions ....

You are correct. In that case they should definitely call it CrusoeVLIW 800+TwinTurbo because everybody knows that turbochargers have lag. This way the customers would know that the CPU needs time to "warm up" and could be used by Sales to explain why benchmarks, etc. need to be run multiple times. Cool!

Re:How will this chip be energy efficient?

[no reply]

i noticed alot of people were wondering how this chip uses such a small amount of power, well it looks like since the instructions (x86 in this case) are software based, instead of being in the processor, thus making the core smaller and easier to keep cool due to less transistors.

someone mentioned loss in horsepower, while this was true for migrating 32bit apps to 64bit instructions, i don't think it would be the case here, since this cpu can 'emulate' the native x86 instruction set.

Re:How will this chip be energy efficient?

[Anonymous Coward]

if you write x86 asm code, then it does in fact matter if the core is RISC or CISC. Unless you use the loop instruction.

Re:How will this chip be energy efficient?

[Mr Z]

CISC vs. RISC is a red herring. Today's RISC machines are as complex as today's CISC machines under the hood. The real difference between VLIW machines and current ones is that the VLIWs are statically scheduled whereas other current desktop and workstation CPUs are dynamically scheduled.

Statically scheduled machines rely on compiler software (in the case of Crusoe, the code morphing software) to take a sequence of instructions and determine what order they'll be issued in and what instruction-level parallelism is available.

Dynamically scheduled machines take a serial sequence of instructions, and use large amounts of complex hardware to detect dependences between the instructions. From this, it determines the instruction schedule on the fly.

Statically scheduled processors benefit from greatly simplified instruction decode and dispatch (since no dependence tracking and no real decision making is required aside from conditional branches). Dynamically scheduled processors have some performance benefits insofar as they can make opportunistic scheduling decisions with the additional information that's available at run-time, and not available to the compiler.

On traditional VLIWs, the compiler is usually only able to statically analyse a program and so it may have to schedule conservatively. A typical example is that the compiler may not be able to tell when two different pointers point to the same thing, so it must serialize accesses via the two separate pointers. Crusoe is able to do a couple things better: First off, the instruction set and hardware provide some mechanisms that allow the machine to speculate sequence of instructions (that is, essentially, make a programmatic guess that a given optimization is OK and check it afterwards, discarding the result on the off-chance it's wrong). Second, it can instrument the code and get on-the-fly branch and function profile data so that it can re-optimize the hot spots more aggressively. Both of these can allow the statically scheduled Crusoe to approach the performance of dynamically scheduled CPUs in the cases where it would've fallen behind. In a sense, embedding the code-morphing software on an otherwise statically-scheduled device makes it a "blockwise dynamically scheduled" device.

Spelling aside on dependences vs. dependencies . The correct term is dependences when talking about how one instruction depends on another's result. This link gives a primer on the types of dependences that can exist between instructions.

As for energy efficiency: If you're able to get your work done in fewer cycles, you can power the clock off sooner or run it at a much slower rate. Power consumption is linear with respect to clock over lower clock speeds, but as you get to higher speeds, various effects cause non-linear increases in power consumption.

Also, keep in mind that energy efficiency is computational work per Joule. The absolute power consumption may are may not be lower with a more energy efficient part. In this case, they're saying 3x faster and 47% more energy efficient. I read that as meaning approximately, if you compare TM5800 to TM8000 at full-tilt-boogie on a given task, TM8000 will probably dissipate 2x as much power (Watts vs. Watts), but do so for 1/3rd as long.

Another thing to keep in mind is that TM8000 will probably be on a newer semiconductor process node than TM5800.

--Joe

Re:How will this chip be energy efficient?

[cburley]

There is a big difference between a VLIW processor and a CISC processor. VLIW is basically a way of carrying out processing more efficiently than CISC, trading off instruction word length and a kind of nanocompiler which works out how to rearrange instructions (and uses a cache of external memory for the rescheduled instructions, btw) for complex decoding hardware and logic for identifying register and pipeline status.

I worked (as a technical writer and compiler developer on) a series of VLIW machines (the Numerix NMX-432, -332, and -464).

To my knowledge, there was no "nanocompiler" that rearranged instructions on the fly, nor was there an external cache that stored the rearranged instructions. I'm 100% sure there was no such thing in the hardware/microcode combo that made up the basic machine ("CPU").

So I'm trying to figure out what you're talking about. Can you give any examples of VLIW machines that do (or did) this kind of on-the-fly rearranging of instructions?

Now, if you're talking about a VLIW machine running software or microcode that emulates a CISC-like instruction set, that's certainly possible, but I wouldn't call that combination a "VLIW machine", rather a CISC-system emulator that happens to have a VLIW machine under the hood.

Or, maybe you're saying it's the CISC machine that has the nanocompiler -- in which case, no, CISC machines do not inherently have those, though Out-Of-Order (OoO) ones could be said to have them, and maybe some also have the cache you speak of.

That (latter) interpretation of your statement seems more feasible, actually, now that I think of it. In which case, I'm not sure I'd call the decoding hardware in a typical VLIW "complex" compared to CISC -- one of the main thrusts of VLIW was to avoid much in the way of instruction-decoding logic, since such logic can be on the critical path in terms of instruction execution, yet is not in any way important to the purpose of the program (i.e. the set of instructions being executed) itself. I.e. instruction decode is, simply, overhead, though it can serve to optimize instruction-stream bandwidth and size (the main advantage for CISC that persists to this day, from what I can tell).

(Lest this confuse anybody: I'm not saying instruction decode is unimportant to executing a program. Obviously, once a program is represented as a series of instructions for a CPU, then some kind of instruction decoder is needed to execute them -- a more complex decoder for CISC, a less-complex one for RISC, and a trivial, though possibly "wide", one for LIW and VLIW. At a higher level, though, programs are better viewed as, for example, dataflow diagrams -- two values "flow" from variables A and B into the inputs of an adder, the output of the adder "flows" into variable C, hence "c = a + b;" is implemented. Viewed this way, the program itself has no need for instruction decoding per se, as long as the data flows from and to memory and is processed through arithmetic logic units (ALUs). So the issue becomes how best to "encode" these flows in a manner that represents a reasonably optimal combination of hardware and software complexity, instruction decode time, and so on. CISC is an approach that makes the instructions take up, overall, less memory and, therefore, require less bandwidth between the instruction memory and the CPU, at the expense of a more complex and time-consuming instruction decode; RISC simplifies the decode but typically requires more memory for the instructions; VLIW goes further down that path, getting about as far away from an "ADD A, B, C" instruction as you can reasonably get. Oh, there are things called dataflow machines that might be even further away, but I don't know anything about those.)

Well...

[coene]

Though I dont think Transmeta has had the kind of success that everyone expected they could have, its great to see that they are continuing to innovate.

It would be great if they came out with more mainstream ways to use their products, such as real viable ATX style boards. It would certainly let their products be used in more mainstream areas. Who wants to develop/search for a custom mainboard, which (due to lack of volume) costs more than anything comparable Intel/AMD. This may in fact be a large contributor to why Asia is such a huge market for Transmeta, they are more friendly to manufacturing custom boards/systems to use the chips efficiently.

Re:Well...

[moonbender]

There is no "real viable ATX style" board for the Transmeta processors, since there is just no need for them in the desktop segment. The main advantage of the Crusoe, low power usage, is no advantage in desktop computers which can draw a (more or less) arbitrary amount of energy. The very low generation of heat would also be an advantage, but there are already low-performance-low-heat Via chips which run on existing hardware and only need passive cooling, so why bother with even lower heat gear.
You don't see desktop computers based on a Transmeta just as you don't see desktops based on StrongARMs.

Re:Well...

[coene]

I mean more for servers actually... If i am looking to fill a 42" rack with shiny new 1U servers, it would be great to build a bunch of of transmeta boxes.

I know that the worlds full of better solutions, but this is still a way for Transmeta to get their stuff into the oem market. To get a rack full of transmeta CPU's, the only solution I know of is RLX System 324 (not to say there arent others -- pardon my negligance of the market).

I guess what I'm saying is that for a company developing a proprietary CPU, they really need to do a better job of making sure that there's technology to work around it (I can see a low power utilization cpu/mobo/powersupply for 1U being a decent seller). If they had a few partners developing mobo/powersupply stuff that was accessible through normal oem/distributor/retail channels, they might have better success in america + western europe.

EEK! When did I turn into a marketing head. I would used to be talking about the technology instead of how to sell it :/

Re:Well...

[hey!]

I think the problem is that everyone's decided they can live with conventional processors on ATX. If you are building a desktop, there is simply no reason to use this processor other than possibly to reduce the noise (not a small consideration for some, but small enough for most).

I really like the trend towards smaller devices though, and as the engineering gets tougher, it would be nice to throw the fans out and make the heatsinks smaller. Small computers like the SS50 are attractive to me, but not quite enough for me to take the tradeoffs needed. However, if I could get a computer with the functionality of the SS50 that was just a tad larger than the CD drive, and had rougly P3 400MHz kind of performance, and didn't cost much more than a good white box PC, I'd jump at it.

The problem isn't fitting this device into the mainstream, it's changing the mainstream so people see the need for this device.

Re:Well...

[Anonymous Coward]

The problem isn't fitting this device into the mainstream, it's changing the mainstream so people see the need for this device.

This statement is so fucking wrong I don't know where to begin.

If the problem is so obscure that you need to forcibly channel attention towards it then it isn't much of a problem.

Good thing I'm just an AC.

Sony and Transmeta - in like Flynn

[ObviousGuy]

Sony's got quite a few Transmeta-based PCs in Japan. My favorite is the thumbpad PC, but I digress...

Transmeta has been promising a lot of things since they were formed those many years ago. Nothing of substance has ever come out, though. Sure we've now got a low-power processor, so what? It comes at the cost of serious lack of speed.

Now they promise 256-bit processors. That's great, but it's completely worthless when any chip that it is attempting to emulate maxes out at 64-bits. Hell, the 64-bit chips haven't even come out yet.

Transmeta is dying. Especially if they've hitched their horse to the floundering Japanese economy.

Re:Sony and Transmeta - in like Flynn

[Qrlx]

That's just what I was thinking. I am rocking the house with 32 bits of athlon XP, what the hell am I going to do with 256 bits? Unless the CPU (which is a very kind term for the transmeta kludge, last I checked) (and no I didn't read the article) can partition itself into 8 seperate 32-bit machines, what's in it for me?

Re:Sony and Transmeta - in like Flynn

[turgid]

Ah, you do not understand the concept of Very Long Instruction Word. Internally the chip's ALU's may be 32- or 64-bit, but with VLIW several instructions (whose results do not depend on each other) go in and are executed in parallel. That's a simplistic explanation. Here is stuff about the Transmeta chips and many other innovative and non-conventional designs. Look at IA-64 and Sun MAJC on the same page.

Re:Sony and Transmeta - in like Flynn

[Hektor_Troy]

"Hell, the 64-bit chips haven't even come out yet."

Now, you may be referring to 64-bit x86 chips, but that is not implied.

Just to correct your statemet, here's a small list of some 64-bit CPUs:

Digital/Compaq Alpha
Intel Itanium (well, I'm not entirely sure if it's available)
PA-RISC
SUN Sparc
SUN Blade
AIX
IBM Power 4
Power G4
IBM AS/400 (and many other in the AS-series)

I'm not entirely sure about all of these though, so if some of them aren't 64-bit, please correct me.

Re:Sony and Transmeta - in like Flynn

[SK-null]

Sun's 64-bit SPARC are named UltraSparc. Sun's Blades are workstations based on Sun UltraSparc CPUs, not a CPU.
Itaniums (first generation are avaliable).
Current AS/400 systems are based on Power4 CPUs too. Don't remeber if the older ones were 64-bit too but I think so.
AIX is IBM's Unix, not a CPU.
You also have 64-bit MIPS and IBM's zSeries.
All up, running and selling.

This begs the question:

[Anonymous Coward]

Is 256 bits really enough for everyone?

Re:This begs the question:

[Troll on ice]

255...256..Whatever it takes.

Re:This begs the question:

[Anonymous Coward]

640 bits should be enough for anybody.

lower power

[Meshach]

Low power consumption is becoming a bigger and bigger issue as chips become smaller, denser, and faster. This design may be an indication of the type of chip to expect in the future

Re:lower power

[gnalre]

We are also looking at the present Transmeta chip. The great advantage for us is its low heat production. This means it can be sealed from the environment in a can with no need for a fan. Which is a great boon for things like shipboard systems.

Chandler: CEO

[banky]

From the article:
Ditzel and Matthew Perry, the recently appointed chief executive officer of Transmeta

Well, it's good to see he's got work lined up now that Friends is almost over.

Re:Chandler: CEO

[martyn s]

Yeah, and in 1854 he also managed to open up Japan after 250 years in isolation. This Matthew Perry guy is pretty accomplished (not to mention old).

Re:Chandler: CEO

[Anonymous Coward]

"Could our processors BE more advanced?" ...

I doubt it's a real 256 bit processor

[soundsop]

I seriously doubt that the internal datapath of this machine will be 256 bits. I think it is safe to assume that only the instruction bandwidth will be 256 bits and the data bandwidth will be 32 or 64 bits or some combination.

I don't think this will be a real 256-bit processor.

Re:I doubt it's a real 256 bit processor

[Anonymous Coward]

Who cares what you think.

Interview, Dave Ditzel (Transmeta founder)

[jukal]

partly covering the subject, is here.

Faster is indeed better...

[coryboehne]

A very nice processor indeed, however I wonder what kind of speeds these things will soon be able to achieve? The thing that really blows me away is when you compare a Transmeta Crusoe TM5400/TM5600 728mhz which on distributed.net can do about 1,966,230 keys a second, with a Power PC 7450/7455 G4 1600mhz that can do a whopping 16,991,648 keys per second! I understand that alpha is far superior, but the question that begs asking is why does'nt everyone go to alpha, especially considering the raw speed that can be achieved?

Re:Faster is indeed better...

[Anonymous Coward]

Lets consider assymbly code for reference of instructions. RISC architecture, your G4, is based on simplified instructions sets which means cheaper hardware and quicker processing, but the trade off is in more complicated operations you are required to use more instructions to complete the same processes in a CISC based (Intel AMD derived) architecture processor. This translates into greater dependancy on more and faster memory for RISC, meaning the cost reduction for the RISC processors is offset by the price of memory. CISC use multiple pipeline and parallel executions meaning in the same processor clock in a best scenario care, it can actually be faster than a RISC, but again this is offset by the fact that CISC processors are more expensive to create becuase it includes these pipelines and extra hardware on the processor. The argument is debateable, but one thing is clear, RISC and CISC processors are growing closer together than they were different in the past, so the lines are bluring.

Re:Faster is indeed better...

[Anonymous Coward]

1600 MHz G4? Tell me oh great one where this can be purchased.

Re:Faster is indeed better...

[Anonymous Coward]

Faster is great, but what good is it if you have to plug your mobile device in for recharge every stinking 15 minutes? Of course what good is a processor that you only charge once a year if it takes almost as long to run rograms, somewhere there will be a balance, but as of now, i believe the worst parts of mobile devices is the battery recharging??

Re:Faster is indeed better...

[SK-null]

Alphas are awfull expensive.
Even a G4 is quite expensive.
And they can't run your x86 software decently
So, we stick to Pentium/Athlon.

Re:Faster is indeed better...

[coryboehne]

But the reason they are expensive (aside from obvious reasons) is the fact that not nearly as many of them are sold. If G4's would sell like intel chips, then you would see the price drop fast and low. As far as the software concern, well, all software generally sucks, so it's just a matter of a re-write. I'm sure MS would do it if you ask REAL nice :)

Re:Faster is indeed better...

[SK-null]

This is so wrong I have to comment.
BTW, Intel x86 and derived aren't the only CISC architectures out there. Its just the last one still being developed.
First, why do you assume because a RISC will take more instructions to do the same job will lead to more dependency on memory?
Do you assume that RISC and CISC instructions have the same size? Don't. And most of the memory problems dependency will be from data LOADs and STOREs, not instructions FETCHs (due to caches).
Second, superscalar execution has been present on RISC chips long before CISC (the Pentium is the only true CISC superscalar CPU I know - capable of executing 2 instructions in parallel).
Even the current hybrid Pentiums and Athlons try their best to make up to 3 OPs in parallel from x86 code (that unfortunately isn't very prone to intruction level paralelism) to feed their RISC-like cores, while modern RISCs are 4 way superscalar.
And then you have all the nice things like speculative and out-of-order execution, which I doubt anyone has ever considered in implementing in a true CISC CPU.
Pentiums and Athlons have the performance and price they have because the sell by the million. There is lots of money to go into R&D for them, putting them at over 2 GHz. And even then they had to use RISC like cores to keep up the pace.

Re:Faster is indeed better...

[Art Tatum]

I understand that alpha is far superior, but the question that begs asking is why does'nt everyone go to alpha, especially considering the raw speed that can be achieved?

Well, the people who can greatly benefit from Alpha AND can afford to buy them in quantities (scientific research institutions and CG render farms) *do* buy Alpha. But it's almost a maxim: the sexier the application, the less of a sustainable market there is. If you want to succeed in the computer industry you have to aim at boring sectors like secretaries who want a simple word processor.

Re:Faster is indeed better...

[Anonymous Coward]

First of all I am sorry you thought I only meant that Intel and AMD were the only CISC derived processors, I only pointed those out as examples and you are right they are not the only ones. When we talk about memory, I include cache, ram, and hdd space.

Re:Faster is indeed better...

[Anonymous Coward]

If you look at history the Alpha range you'll see it was becoming harder to increase the MHz. It's also best at floating point calculations.

Strange

[Anonymous Coward]

It's strange seeing an announcement from Transmeta BEFORE the product is developed. Maybe their previous "silent run" has taught them something?

It's not a 256b datapath, but a 256b VLIW word...

[nweaver]

This is the size of the INSTRUCTION which is encoded, not the datapath.

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

Fourth, transmetas claims in the past have been so full of hot air, so why should we believe anything they say now?

Here's a dumb question...

[doorbot.com]

...but does this mean the new Transmeta chip could effectively emulate a 4-way 64-bit processor system? Or is my Sega-like addition of bits incorrect? I guess, though, that by starting with a 256-bit processor, Transmeta can emulate processors for years to come...

32-bits, 64-bits, 256-bits .... what's the limit ?

[Taco Cowboy]

First there was that 4-bit microprocessor, then it went to 8-bit, then 16-bit, 32-bit, and 64-bit.

When Transmeta announced it's 256-bit microprocessor, I'm not surprise.

However, I do have a question ....

Is there a theoretical limit on the maximum
bit-path for microprocessors ?

Or in other words, will we see microprocessors with giga-bit (or even exa-bit) path ?

OS support?

[GoatPigSheep]

Ok so who's coding 256-bit linux? :)

Re:OS support?

[Anonymous Coward]

fuck you.
arrogant linux asshole. some people have feelings, and i hope yours are becoming like your ass - repeating exposed to burst after burst of hot man juice.

Re:OS support?

[jd]

IMHO, Linux should bite the bullet and become word-independent. We don't want the same hastles as we had when it took ages to get the kernel 64-bit clean, all over again, every time a new word length comes out.

There is absolutely no reason I can think of that all the size dependency issues (for data, address, etc) can't be shifted into a layer between the kernel itself and the underlying processor support. If you were to do that, then someone could come along with a 4096-bit (data), 256-bit (instruction), 512-bit (address), 8192-bit (register) processor, and you wouldn't need to give a damn. Just copy an existing header file, shove in the new constants, and the kernel would support such a layout from day 1.

Is this possible? Sure! There's nothing magical about the sizes used for data structures - they're just sizes used because they are. If a kernel pointer took 1K, would it really change the logic any? No. It would just mean that the pointer took that much RAM, and could point to 2^1024 definable points in memory.

The only times you actually NEED to know the size of a data structure are when you're checking for out-of-range conditions, or when you're streaming in/out. The first just requires a pre-defined set of constants (eg: MAXINT) to reflect the bit-lengths. The second is more complex, as byte ordering becomes important. If you're putting a 32-bit number into a 64-bit structure, and the endianness isn't the same, you have to first convert the 32-bit number to 64-bits, in order for the endianness to convert correctly.

This doesn't work too well, the other way round, though. 64-bits can hold more data than 32-bits, so if you have code which assumes you've the full 64-bit range, it'll break.

BUT, this is the crux, what happens if you don't assume, but ask? What happens if the kernel interrogates the hardware, to find the bit-lengths? What happens if user-land software doesn't assume specific ranges, but enquires at run-time? (eg: Things like sizeof() become system calls)

Sure, things will run slower on any given hardware platform, because none of the software would be making assumptions about the nature of the hardware. Any hardware-dependent optimizations would need to be made at run-time. (eg: when loading an application, it would be "linked" with the hardware layer, unknowns would be resolved, and the code tuned to the bit-lengths in use.)

All of this is certainly possible, and certainly practical. The only real question is whether it is even remotely useful. At any given time, is there so much diversity that hardware-independent layers would have any actual value to anyone? If not, then although you can do it, why bother? It would be easier just to hand-tune the system each time you moved it.

(X is a classic example of a system that could be hardware-independent, but is actually heavily hand-tuned. Manufacturers who want a performance better than that of a slug do some intense work on tuning X for specific hardware/software combinations.)

VLIW at IBM Research, Transmeta & IBM married

[jukal]

See IBM's research on the VLIW subject.

"We developed an experimental prototype of a VLIW processor, capable of performing multiway branching and conditional execution, which is currently operational. The prototype has helped us investigate some of the hardware constraints in building VLIWs.
This processor executes tree-instructions within a ``classical'' VLIW architecture, that is, fixed-length VLIWs with preassigned slots for the different operations. The register state consists of 64 32-bit general purpose registers, 8 single-bit condition code registers, 4 memory address registers, program status word register, and some special registers. Each Very Long Instruction Word is 759 bits, which include..."

Now, when we know the relationship between IBM and Transmeta, can you combine the results of these two 'projects'. :)

the first 256-bit OS..

[bo0push3r]

windows 256.. due out in 2256.

Re:the first 256-bit OS..

[Anonymous Coward]

Hmm, a bit off topic I guess, but do you really think MS will last that long?

Re:32-bits, 64-bits, 256-bits .... what's the limi

[NanoGator]

I am not, by any means, very well educated on this topic. I would venture, though, that the number of bits is not limited by anything other than practicality. I have a difficult time imagining that a 1024-bit machine would be useful today.

But who knows? Maybe when volumetric holograms come into play we'll see a need for numbers that big.

I do think we're due to move off of silicon soon, though, and move to something organic. I'm really curious what'll happen when we replace bits with neurons. ;)

Memory Addressing, Parallel VLIW Issues

[peatbakke]

This is not memory addressing, it's just the width of the instruction pipeline -- I'm inclined to think this chip will probably have 32-bit addressing to be IA32 friendly, but of course, I don't know for sure.

There's nothing too spectacular about 256-bit instruction paths in VLIW processors, but I'm not sure this will offer the caliber of benefits they claim it will: VLIW instructions (which are usually bundles of smaller, discrete instructions) are by nature very complex beasts, and trying to shove two down the pipeline without the instructions stepping on each other's toes is a difficult process.

But, of course, I'm not working at Transmeta, so I really can't say what wonders they're working over there.

Re:Memory Addressing, Parallel VLIW Issues

[bentini]

Umm, actually, Pentiums and their later brethren ahve 36-bit physical addressing off-chip. Logical addressing-wise, I'm not sure. I never understood x86.

Re:Memory Addressing, Parallel VLIW Issues

[be-fan]

36-bit physical, 32-bit logical on P6+. Never understood that. You have to use "memory" windows to access different 4GB chunks of the 64GB space.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[coryboehne]

Hopefully quantum computers will have taken over long before we get anywhere near terra/exa-bit processors, however I could possibly see getting into the giga-bit range.

hobbyist motherboards?

[X_Caffeine]

I think Transmeta is really missing the boat on not having any OEM motherboards available for system builders and hobbyists. You could make a case for this market being the reason behind AMD's success with the Athlon.

I'm speaking out of self-interest, of course. I'd like to build a home, rack-mount style server with ultra-low energy requirements. As it is, I'm thinking about going with an iMac motherboard and Darwin, but I'd much rather use a Transmeta system with a standard Linux distribution.

Perhaps transmeta will change strategies

[papasui]

I never thought they could compete effectively in the competitive x86 market. But here's where they really could, instead of trying to emulate other peoples software, build an OS tweaked to that processor so tightly that the lack of general speed is negated. Proprietary systems have the potential to be very very fast, because their developers know all bits and pieces of that specific system. For example console systems (and I use this as my example because I've done gameboy and gameboy color programming) which are in general very much slower than a comperable pc but because the system is designed for a specific purpose and the developers are well versed in all the ways to squeeze a couple extra juice of it they are hard to compete with in terms on games. Transmeta should imho, focus completely on embedded systems that use their own OS and software to really shine.

Architecture is not relevant

[HiKarma]

While it's all very interesting inside, if all they ever do with these chips is emulate a Pentium, then all they are to the market is a low power pentium.

Thus all the market will care about is how much does it cost, how much power does it use and how fast is it compared to the offerings from Intel and AMD.

Is that a battle Transmeta can win? Intel can always pretend to have a better low power pentium around the corner, and they might not even be pretending.

Now, if they could use it to make a machine which can run both Mac PowerPC and x86 software are high performance, that might be something that would bring in users.

Transmeta? They still around?

[Anonymous Squonk]

I haven't seen a company that promised so much and delivered so little since Pixelon.

Great...

[SecretAsianMan]

...now we can have 64-digit hexadecimal constants! This is certainly a much-needed advance!

256 bits

[akuma(x86)]

This marketing-speak is silly. They will fetch a 256 bit VLIW word. I guess the Itanium is a 128 bit machine since it fetches a 128 bit word. By convention, when someone says they have a 64 or 32 bit processor, they are referring to the datapath. The width of the ALUs and the number of bits used to address memory.

If a really low power processor was useful, then Intel or AMD would already have an ultra-low power product out the door to fulfill the market need.

Transmeta claims they can get equivalent performance at much lower power. This is a dubious claim given that their past products have fallen far short of this goal. Their customers are few and far between and the stock price has reacted accordingly.

Re:256 bits

[Art Tatum]

If a really low power processor was useful, then Intel or AMD would already have an ultra-low power product out the door to fulfill the market need.

Really low power usage IS useful. But not enough people care for Intel or AMD to put a lot of effort into it.

CORRECTION (re: Memory Addressing, Parallel VLIW)

[peatbakke]

(clicked the submit button on accident .. argh)

By "pipeline" I meant instruction size. It can't be said for sure if it's a 256-bit wide datapath, but it seems that anything less would make the chip even harder to build.

Later when I referred to shoving "two down the pipeline", it was in consideration of size of the previous 128-bit VLIW instructions, not that they were attempting to parallelize the execution of the previous VLIW instruction set.

.. just trying to clarify what I meant. Heaven forbid it be misinterpreted .. ;-)

Re:32-bits, 64-bits, 256-bits .... what's the limi

[jukal]

> Or in other words, will we see microprocessors
> with giga-bit (or even exa-bit) path ?

Using current technologies (DNA&Quantums excluded) the main problem will become the size. At some point, the barrier will be hit - there is a limit for the number of transistors you can fit in certain size

My quess is, however, that we will see a true 1024 bit processor by year 2008. I also quess that at this point we have seen the best the current technology can offer, and we will start shifting away from transistors. Majority of our computers will be based on these alternative technologies by year 2015.

Save this for future reference. :)

Transmeta

[olman]

So what happened to the lawsuits? Investors were suing transmeta because their processors were not fast enough..? I'd like to think the suits were dismissed as frivolous, but.

In any case, it's good to see that people are finally doing something beyond souping up the old 386 architecture. Of course, AMD's souped up version garners more positive press than Intels genuinely new design (Itanic). Goes to show new trick's not necessarily a better one. And as far as I understand, AMD did some straightforward changes (MORE REGISTERS!!) that make the core a lot better.

Re:Transmeta

[mikefoley]

FWIW, Transmeta licensed AMD's x86-64 designs and could probably morph it without much of a problem.

Remember, the Crusoe is "different". Rules apply diferently.

Dumbshit moderation.

[Anonymous Coward]

I like how asking a question so he can understand the topic at hand is modded redundant. He, like me, doesn't see the benefit to 256-bit processors when 64-bit is still having difficulty gaining market share. It's kind of an important question when we're still discovering why we should care.

Japan rules

[Anonymous Coward]

Japan rules. They are the technology kings and they have the best looking chicks.

Also, Hemos is my bukakke bee-yatch!

ObXserve remark

[Anonymous Coward]

I mean more for servers actually... If i am looking to fill a 42" rack with shiny new 1U servers, it would be great to build a bunch of of transmeta boxes.

If that's what you want, you should consider Xserve boxen. Rack 'n Roll!

Re:ObXserve remark

[coene]

They look interesting, but hellishly expensive.

Transmeta Motherboards here

[willpost]

Transmeta Crusoe TM5400/TM5600/TM5800 5.25-inch SBC
http://www.ibase-i.com.tw/ib755.htm

They've got more Transmeta motherboards, including a CPU PCI board.

I bought the first one that came out and I like it. You'll have to find a way to mount it to an ATX case since it's one third the size.

Other Transmeta Products:
http://www.transmetazone.com/products.c fm

Re:VLIW at IBM Research, Transmeta & IBM marri

[taniwha]

IBM is a BIG company, they not only have a research arm (who it seems do VLIW research - like many companies and universities - ILP research has been very popular the past decade or so) - but they also own fabs and build chips for people - I'm pretty sure they were building TM's first chips and that's what that article was really about.

Re:VLIW at IBM Research, Transmeta & IBM marri

[loony]

> Now, when we know the relationship [wired.com] between IBM and Transmeta, can you combine the results of these two 'projects'. :)

You can't - its after all not open sourced ;)

Re: 32-bits, 64-bits, 256-bits .... what's the lim

[Black Parrot]

> First there was that 4-bit microprocessor, then it went to 8-bit, then 16-bit, 32-bit, and 64-bit. ...will we see microprocessors with giga-bit (or even exa-bit) path ?

No one should ever need more than 640 bits.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[child_of_mercy]

neurons are SLOW

brains are, however, massively parallel.

I think you'd get more grunt and reliability from massively parallel silicon in this century than from any artificial neuronic configuration.

But really your quantum computers, which can parallelise across their own probabilities will almost certainly be the next major leap.

Japanese chicks? personally I like women with tits

[Anonymous Coward]

read the subject, dickwad.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[martyn s]

What's a "true" 1024 bit processor? What does it mean that a processor is 64 bit? 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, but what does that even mean? What can a 128 bit proc do that a 64 bit proc can't and a 32 bit proc can't? Please explain, I'm very curious. Or point me to somewhere that might explain.

Linux Torvalds

[Anonymous Coward]

Linux Torvalds works at Transmeta, he'll probably port Linux to the New 256 bit Transmutor himself.

Re: 32-bits, 64-bits, 256-bits .... what's the lim

[Gimpy-Joe]

hey just a thought black parrot but you should probly stick to powers of 2... we all know how binary works right... 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048 etc sorry blackparrot but i'm doubting you'll get your 640 bit processor but keep wishing.

Buggy.

[Futurepower(R)]

You forgot to say: ... and really buggy. The installation code will be 5000 characters long by then. Your computer will be completely controlled by MS computers. The EULA will give Microsoft complete control over all your possessions. Microsoft will be the state religion. You will be required to worship a statue of Bill Gates.

Re:Japanese chicks? personally I like women with t

[domninus.DDR]

What about the super hot anime cat wemon that we have the japanese to thank for?? Thanks for thinking that through AC.

Re:Japanese chicks? personally I like women with t

[Anonymous Coward]

I love cat lemon women.

Re: 32-bits, 64-bits, 256-bits .... what's the lim

[Jugalator]

It was just a bit of Microsoft humor and nothing to be taken seriously. :)

Have one and love. Get one if you can.

[Mortenson]

I have a Toshiba Libretto with a 800Mhz Crusoe chip in it and love it. You can actually run the thing for a few hours. Every other notebook has always said 2.x hrs but usually runs out in around 90 minutes.

But the best thing is the low amount of heat that the thing kicks out. Anyone who has ever sat with a P3/4 notebook on their lap for any amount of time knows how hot they get. These get a little warm after an hour or so, but not hot.

Bought mine in Japan, not sure what is available elsewhere.

Cheers.

Re:Have one and love. Get one if you can.

[Mortenson]

Of course mine isn't 256 bit :-)

Yawnnnnnn

[Anonymous Coward]

Oh great, another CPU and my broadband speed is getting slower and slower. Why the hell are we keep having faster and better CPU and broadband technology and availability is standing still?

Re:Yawnnnnnn

[Anonymous Coward]

Mod this up to 5 and send a copy to congress please.

I don't get it!

[Dr. Spork]

It looks to me like Transmeta chips are on absolutely tiny dies and use very little energy. For all those compromises, the performance seems acceptable. Now, I'm not a chip designer, and that may be reflected in my next comment... but I'm asking myself why don't they just stick more transistors onto the die, and maybe more cache? I mean, if a Crusoe were scaled up to the die size/power consumption of a P4 or an Athlon, it seems to me it would kick their asses, even with the code-morphing handicap.

Now I know it's more complicated than just adding more transistors. Still, though, they seem to have a good design, and it seems to me like they should just add more horsepower to each part of the chip. It would have the potential to be a great server chip, and if my wildest dreams came true, it would outperform the Motorolla's best chips by such a margin that Apple would pay Linus to write a code-morphing routine to have the chip emulate a PowerPC. It would be a seamless transition for Mac users, and it would make Macs competitive again for price-conscious performance users.

Re:I don't get it!

[slittle]

Cache is huge. Find some closeups of processor cores, and you see that the cache of an average desktop processor covers up to half of the space, maybe even more.

That's not cheap to make, and no doubt power hungry, which is the reverse of what the Crusoe does best. Besides, there's no guarantee more cache will help given it's current design - if you want a smokin' processor with lots of cache, use one that was designed for that purpose.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[jukal]

In my definition, a true 1024 bit processor would be a 1024 bit chip optimized for 1024 bit code, must have address size of 1024 bits and 1024 bit databus, natural word size must be 1024 bits.

correctify my mistakes :)

What I want from Transmeta

[the grace of R'hllor]

I don't care about mobile.

I don't care about power efficiency except as a means to an end.

And that end is a passively cooled machine of sufficient performance to run a desktop workstation or server. I'd like to replace my aging PPro200 with a passively cooled machine, and Transmeta seems to be able to deliver that.

So why don't they do that? I think there's a market there, too. A Transmeta mobo and processor is all that is needed, yet in the Netherlands, I can find neither...

Of course, 'cheap' would be a nice property of such a system too, though I don't know if Transmeta could deliver that.

Re:What I want from Transmeta

[Graymalkin]

You ought to look into the C3 from Via. It only needs passive cooling and runs off of a stock Socket 370 motherboard which wouldn't be that hard to find with passive cooling of its own. A well mounted quiet hard drive and a good power supply and you'd be hard pressed to tell if the PC was even on.

Re:What I want from Transmeta

[Anonymous Coward]

> A Transmeta mobo and processor is all that is
> needed
>
Amen to that. Especially since any performance difference could easily be remedied with a dual- or quad processor arrangement on the motherboard.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[plarsen]

Okay, first they raise the bits, then they go over to alternative media, neurons ans such. And in about 100 years they have reinvented what we already have billions of -> Human brains. Then they ask themself, why did we invest all this money on this when we had it all the time?.

Re: 32-bits, 64-bits, 256-bits .... what's the lim

[hardcoredreamer]

i sure got it first time through..

Correct me if I'm wrong

[theolein]

Doesn't Transmeta use a software instruction translator to translate x86 instructions to their processor? That means it's transparent whether you write your code for 32 or 64 bit x86, doesn't it?

I have this funny feeling that the one company who could really get the most out of Transmeta's technology is the one company that won't: Apple. Given Apple's constant problems with Motorola and G4 deliveries, this is one processor that could give them a boost. I have no idea though. This is just a question.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[Paul Komarek]

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

Re:It's not a 256b datapath, but a 256b VLIW word.

[bentini]

A) Because Transmeta is VLIW, they don't speculatively execute. That's the whole point, Instruction Fetch/Decode (two of the bottlenecks in traditional architectures) have been more or less eradicated because it's so simple. So, really, that point is completely not true. At the moment, my lab group has a chip whose instruction size is about 5-600 bits (I can never remember). Impressive, until you realize that it isn't.

B) The translation doesn't have to be that great. They're still performing fairly competitively with Intel chips.

C) Pentiums don't play well enough. Transmeta can simulate fairly well a several hundred megahertz (probably about 4-500) Pentium III. Also, Intel is notoriously bad at doing such things. Their memory is not written down on how to make such chips, but only remembered in the minds of the workers. It would be VERY hard for them to do that, actually.

D) Transmeta based solutions have often employed other cool ideas in terms of power consumption: Better LCD's that don't need backlights, e.g. Not perfect, but getting there.

E) Transmeta's solution is so amazing that, even if it hasn't revolutionized the world, it has changed the course of Intel's strategy non-trivially. Plus, it's awesomely cool.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[bentini]

*sigh* Slashdot headline misleading... Film at 11.

Here, the 256-bits refers to the instruction word, not the data-word size. These are completely different things. If you're going by this, then your x86 could be considered up to a 48-bit machine or so. The TMTA chips are still 32 or 64 or 48 or something like x86 is. this is just going to mean that because it's VLIW, it can do 8 ops per cycle per pipeline stage instead of 4. Cool, but not any more revolutionary than anything else TMTA has done.

Re:It's not a 256b datapath, but a 256b VLIW word.

[Anonymous Coward]

Fourth, transmetas claims in the past have been so full of hot air, so why should we believe anything they say now?

Because Linus works there.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[martyn s]

Yeah, there was some post higher up which seemed a little silly: "are we gonna have gigabit or exabit cpus one day?"

So what are you saying exactly, that the number of bits that a CPU is rated only means the total number of RAM bits that can be addressed? In other words, a 32 bit CPU can only address 2^32 bits of RAM? Is that the only real difference?

If it is, I can't imagine any computer in the 60's and 70's being able to address 2^64 bits of RAM.

By the way, there are 10^81 atoms (supposedly) in the Universe, which is somewhere between 2^269 and 2^270 (to be precise, it's 2^269.07617568587635017749587378908).

Friends?!?

[SuperJames_74]

"...Ditzel and Matthew Perry, the recently appointed chief executive officer of Transmeta,..."

Wow - Chandler is the CEO of a CPU company?!?

The Japanese don't play dice with the Universe

[Graymalkin]

There's a very interesting difference between gadget production in Japan and in the US. One important aspect besides pure technolust that drives the production of all forms of technological toys is the expected return. In Japan a tech product needs to only sell about 25,000 units in order for a company to see it as viable. In the US that prospect is ten times higher at 250,000 units. Ergo, Japan sees far more keen little toys because there's no impetus to sell hundreds of thousands of them which allows for a much larger number of what the US would see as production failures. The logic stems from the fact there is far more techno toy demand in Japan so a minimum demand product that just barely sells out its 25,000 unit inventory might be succeeded by a subsequent product that outsells production capability driving the price up through increased demand. There's also a ton of local intranational production facilities as well as a close proximity to Taiwan and Korea which vastly lowers the cost of all the microelectronic components because they don't need to be shipped across the Pacific. I know the pangs of technolust well, I want one of those Sony PCG-U1 in a way I'm not entirely comfortable with feeling about a computer. In short that is why Japan sees so many damn cool toys. The increased demand allows for smaller successful production runs and more product variety.

Re:The Japanese don't play dice with the Universe

[beme]

Not sure if the follow-up to "... I want one of those Sony PCG-U1 in a way I'm not entirely comfortable with feeling about a computer." is 'but I can't buy one because they are too expensive' or 'but it's too much of a pain to get one from Japan' or something else, but (ugly sentence) if it's the middle option, there's a company that looks like it will sell you one: http://www.dynamism.com/u1/pricing.shtml (I know nothing at all about them.)

Re:The Japanese don't play dice with the Universe

[p3d0]

Translation: they have more toys because they want more toys.

Re:The Japanese don't play dice with the Universe

[Graymalkin]

Thanks for the link but I've been to that site a number of times drooling. If i had an extra 1800$ to spend on one I'd get one. Right now however stuff like rent and car payments come first. I think it is high time I bring a frivolous lawsuit against cirgarette companies or McDonalds or some other national cash cow and get myself some spendin money!

Re:The Japanese don't play dice with the Universe

[Art Tatum]

Can I tag along and make it a class action suit? I'd like to get a cluster of Alphas....

Re:It's not a 256b datapath, but a 256b VLIW word.

[Anonymous Coward]

So, like, has Intel bought you lock stock and barrel, or are they just leasing?

Re:It's not a 256b datapath, but a 256b VLIW word.

[jeti]

Would it be possible to pack instructions
from different threads into one VLIW?

Re:32-bits, 64-bits, 256-bits .... what's the limi

[Anonymous Coward]

That would mean that my 8bit Commodore 64 is really 16bit, because it has a 16bit address bus (it can address 64 kilobyte).

Re:Have one and love. Get one if you can.

[Senjaz]

Only 2 hours?

Think I will stick with my TiBook G4, more powerful and 4 hours of battery life in real use with Mac OS X. If you're not bothered so much about the power then an iBook has longer battery life again.

Ok so it doesn't run x86 code (excepting with VirtualPC) but hey we all use some form of UNIX here and any app you're likely want to run works on one.

Also I would admit the G4 gets quite warm but generally only by the mains port when it's plugged in and even then only when its actually busy.

So what's the point with these transmeta chips? It doesn't matter how technically clever it is in the PC market it doesn't really offer an advantage.

I'd rather put it this way - 8% outside Japan

[Kjella]

...I've looked at some Transmeta-based notebooks when I was over in SE Asia this spring, which was almost exclusively Fujitsu Lifebook series. These fill a niche, being the smallst of the Ultraportables and I'm sure it fits right in between the Palm and the standard notebook as a tech toy, but I don't think it's an expanding marked in Japan or any viable marked outside Japan.

Quite frankly, the reason I didn't get one is that it ran like a limping turtle. Then again I'm rather picky and ended up getting a Toshiba Portégé 2000 instead, but that's just me. Chokes out after 90-100 mins with primary but lasts a good 6 hours with the included secondary, sitting outside, screen to max brightness and using the built-in WiFi. Everyone but my wallet and a few jealous friends are happy :)

Kjella

The real question it begs

[Anonymous Coward]

What would a beowulf cluster of these be like?

cheapest supercomputer based on transmeta

[peter303]

When you include the total cost of operation (TCO), a TM computer cluster is a third of the price of alternatives. TM clusters have smaller footprints because you can pack the cooler CPUs closer together. They use considerably less power.

The point?

[Ravenn]

Simple. A larger number means a better chip.

Pure marketing. Nothing more. It'll be how long before it's available? And how long again until there's apps written for it? These are the questions that aren't being asked by the discerning media who are reporting it.

Re:The point?

[Jobe_br]

Just a quick FYI - apps aren't *written* for the Crusoe architecture ... the only *app* per-se, that's written for it is Transmeta's code-morphing engine, which morphs the 32-bit x86 instructions into VLIW instructions for the Crusoe chip. Of course, the morphing engine could also handle 64-bit Itanium instructions, 32-bit PPC instructions, 64-bit UltraSparc III instructions, etc. Just a matter of Transmeta devoting resources to write their morphing engine for the particular instructions (and ensuring an adequate level of optimization is achievable). I imagine the code-morphing code is written in a relatively low-level language (assembler or something close to it) ... or, its compiled from C and then optimized by hand by some very skilled engineers. In either case, the 256-bit-ness of the processor will only affect this code, not any other code.

Re:The point?

[Anonymous Coward]

That's basically right. I was an intern at Crusoe last summer. I can't say much (NDA, and why I'm posting AC). The code morpher is entirely asm. The developer kit they offer gives advice on how to write x86 code that will be optimized when the morpher looks at it, but they won't give any details on the crusoe instructions (so they won't be tied to a specific architecture).

Linus' work with the kernel was to make sure the asm stuff didn'tmake any poor assumptions.

for travelers?

[f00zbll]

I have a Sony Vaio, which has a 900mhz celeron. For short trips it fine, but on the plane it was way too big for those little trays. The thing ran for 4 hours with 2 batters, but my flight was 6 hours long. If some one had to fly from US to Asia, you'd need 3 or more batteries.

Most people don't do that, but some do. Anyone know how long a laptop with transmeta chip will run in real life?

Not hypothetical PR bs, but from first hand experience.

Re:for travelers?

[Anonymous Coward]

I got fujitsu's P2040 laptop. It runs transmeta's 5800 chip at 800mhz running, now win2k, was winXP home. It runs fine, I'm able to watch 2hr dvds without it dying on me. I've ran 2+hrs on the main battery before and sat through a 5 hour class with the extended battery. The only thing that heats up on this laptop is the wireless ethernet adapter. I was also worried about coding problems, but I'm able to do raw assembly as this processor mimics a x86 processor.

transmeta's income statement

[sketchkid]

transmeta's income statement this was released on the 16th. i think it has some interesting numbers. if you look at net income (loss) at the bottom and add all 4 quarters up, thats the loss for the past 12 months. ouch, $179,432,000

Re:transmeta's income statement

[The_Dougster]

It can't be cheap to go toe-to-toe with Intel and AMD, not to mention all the other "embedded" cpu guys. Hope they can hang in there long enough to grab up some real market share. From what I have read about the Crusoes (disregarding FUD) anybody who has one seem to think its great.

Re:transmeta's income statement

[sketchkid]

is there anything new regarding their 'power performance' (crappy self-made term). last time i remember checking benchmarks showed the crusoe wasnt saving a significant amount of power. this is the thing that would get me buying a notebook.

Whole lotta DIMMs

[Ilan Volow]

If you buy a computer with that new fangled Transmeta chip, where the hell are you going to find 2 to the 256th power bytes of RAM you need to max out your machine?

Re:Whole lotta DIMMs

[Glumdalclitch]

Quantum computers have the same problem.
Luckily there's such a thing as desktop black-hole data compression and Hawking radiation I/O.
With "Ultimately Large Instruction Words" one could get rid of the central CPU clock altogether, which happens to be exactly what Einstein did.

Re:Whole lotta DIMMs

[The_Dougster]

I hope Microsoft never gets ahold of one of those quantum computers... once Windows X$ is installed they will be slower than a Commodore 64, and thats before you get to run your application software. I think they should re-write Windows XP entirely in hand optimized assembler. They have who knows how many billion dollars, I want to see some friggin real performance.

How come a 486 with Windows95 feels faster than a Pentium III with Windows 2000? It sure as shit doesn't do anything different now than it did then. They must have re-written the whole OS as a VBA module for Excel or something to make it such a pig.

Maybe the Crusoe can code morph Visual Basic code and run it natively? Perhaps the fabled hardware Java processor of yore? Whatever it does Linus works there so it must be pretty damn cool.

Re:Have one and love. Get one if you can.

[Lahjik]

After much looking, I finally decided on getting a Fujitsu Lifebook P-2000 for my wife. She needed a laptop, but not a serious desktop replacement. This was more of a when we don't feel like sitting at the desk to work type of deal. The 800Mhz Transmetta Crusoe and 256mb of RAM seems to be only slighly slower than my main desktop system (800Mhz AMD with the same RAM). This laptop has the added advantage of having a built-in DVD-CDRW combo drive and a VERY small form factor. The lack of a docking station will pretty much limit the P-2000 to secondary machine staus, but it is a nice travel notebook. Starting at $1500 ($1800 for loaded with built-in wireless), they are pretty reasonably priced for what they can do. The only complaint I have with it is that the right shift key is small and a bit out of position (the other side of pg up), but I have just switched to using the left shift key whenever possible. I am actually considering moving towards one of Fujitsu's P-1000 sub-sub notebooks with a touch screen to serve as both my mobile notebook (I travel a lot in a local area) and my Jornada 720.
These are just two other Transmeta products that are widely available in the USA. The P-2000 is even sold by some of the major electronics and computer stores (like Best Buy). As I said, I have been very happy with our Transmeta based Fujitsu and I look forward to buying another!
Chris

Re:Have one and love. Get one if you can.

[mattdm]

Your TiBook is about ten times bigger than a Libretto. If I wanted something that huge, I'd carry my desktop PC around.

Re:Have one and love. Get one if you can.

[mattdm]

Do you have Linux running on it? I have a Libretto CT50 which I'm quite attached to, but its maximum of 32MB of RAM is killing me.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[SK-null]

Actully x86 instrucions have variable sizes, from 1 to 17 (yep, seventeen) bytes.

green destiny

[simpl3x]

this was the point of developing a supercomputer using transmeta processors. utilizing a customized os and software to fully take advantage of the processor's capabilities. this is the future, and i cannot wait for the 6000 system on a chip.

Jabba the Hutt

[Rupert]

In EpI he his seen moving forwards onto the balcony overlooking the pod race, apparently under his own power.

Re:Have one and love. Get one if you can.

[Anonymous Coward]

The Fujitsu P-2040 which I have has the ability to run Linux with only a small bit 'o pain. Just do a Google search for p-2040 and linux.

VILW is the opposite approach from RISC.

[flatrock]

RISC uses a reduced number of instructions. It gets it's speed because the decoding of the instructions can be done with a hardware decoder very quickly.

CISC uses a relatively larger set of complex instructions. Those instructions are typically decoded using microcode. Intel takes the approach of decoding a large quantity with a massive hardware decoder, which is faster, but takes up a lot of silicon.

VILW uses a very long instruction word. The instructions typically have to be decoded by microcode, because a hardwired decoder would be prohibitivly huge. It gets it's speed by taing a single instruction that can define multiple task which the processor can perform in parallel. The instruction set is designed to take advantage of the different types of opperations that can be performed in parallel, and a very complex compiler is required to create the most efficient machine code. The end result is a processor that gets a lot more done per machine cycle and can therefore run at lower clock speed and still perform well.

It's the lower clock speeds that really help the power disapation. Heat is produced by resistence to the flow of electrisity, and the resistence in a capacitor goes up quickly as frequency (clock speed) increases. Even though a VILW processor is doing more and creating more heat per clock cycle, they can end up with less heat at the same performance level.

Imagine...

[mongoks]

...a Beowulf cluster of 256 bit CPU's.

Re:Have one and love. Get one if you can.

[Anonymous Coward]

Why does this sound familiar?

"The wifey needed a new laptop, so we got her one, and I love it!"

bypassing the code morph layer

[Anonymous Coward]

Is it possible to bypass the code-morphing layer? If so, couldn't people just port directly to that architecture instead of using x86/PPC/etc. and translating it, which, I assume, would speed up the whole thing, right?

Re:bypassing the code morph layer

[andrewm]

No. The CPU loads CMS from either a serial or parallel flash at reset. The VLIW architecture is completely hidden, proprietary, and top secret.

I know as I helped designed a Crusoe product. I have one as my gateway actually ...

processor : 0
vendor_id : GenuineTMx86
cpu family : 5
model : 4
model name : Transmeta(tm) Crusoe(tm) Processor TM5400
stepping : 3
cpu MHz : 531.483
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr cx8 cmov mmx longrun
bogomips : 1048.57

Re:bypassing the code morph layer

[The_Dougster]

Ok, what if the "code morph layer" were somehow modified instead to execute a more efficient type of code? I took some comp eng classes back in college, so I know that there is a myriad of ways that one can encode a machine language instruction. For instance, a Crusoe could probably be made to run trinary code or something equally weird. I find it tough to believe that X86 instructions are the best there is... like what about emulating PA-RISC or Itanium or Sparc or Mips, or who knows what?

I hope Linus is going to drop some bomb with 256bit Midori Linux or something wild that is going to do to the CPU world what 3Dfx did to the video card world! Go Linus! Go Transmeta! Yaay!

Heh I have a couple old SA110 Netwinders and I just wish they were the new Crusoe models. They are damn fast for the little toy servers that they are but a 600MHz Crusoe with FPU built in would totally blow them away.

The low power deal is very important to me. For instance I run the `Winder server headless 24/7 as my firewall/router/webserver and it doesn't cost jack shit. Try that with a dual cpu pentium-iii and see how fast your electric bill shoots up! A server is pretty worthless if you can't afford to run the thing all the time.

Crusoe-based Java server??

[bitfoam]

It means that, just like JIT compilation in Java, the first time through a loop is slower than subsequent accesses.

Whoa..! Just had a crazy thought. Couldn't a Transmeta chip, with appropriate modifications to the code morphing layer, be made to run Java bytecode "natively"? Would this make a really nifty Java application server, or am I completely off whack here?

Imagine a Transmeta box running a JVM specially built to take advantage of the Crusoe. Would this be a hotrod that runs Java bytecode at "native" speed without the initial JIT latency? Or would this be a fizzle given Java's other limitations (e.g. tendency to have poor memory locality)?

Curious... yeah this is a niche market, but wow, this would be an interesting play for the server market if it were possible.

Re:Crusoe-based Java server??

[Sunda666]

heh.

Morphing x86 asm is one thing. Morphing JAVA would be... difficult ;-)

Alas, this would violate one java spec : VMs must be slow as hell...

Re:Crusoe-based Java server??

[Mr Z]

Actually, I believe this article says as much:

The technology could also be applied to other types of chips, according to the patent. For example, though the patent describes in detail how Transmeta's process would work to create a fast chip that's compatible with Intel silicon, the technique could work for "any family of ... computers," even Sun Microsystems' Java technology, the document says.

--Joe

Oh great

[Our Man In Redmond]

Now we can look forward to a Y82,136,525,314,815,442,306,154,117K problem.

Re:It's not a 256b datapath, but a 256b VLIW word.

[Jobe_br]

I could be wrong, but I think this would require that the code-morphing software be aware at a "higher level" - i.e., the OS currently manages context switches, so the code-morphing software doesn't have any sense of there even being multiple threads ... for it to pack instructions from different threads into a single VLIW, it would need to be more integrated with the OS' scheduling algorithm that handles context switches. Unlikely, I suppose.

Re:It's not a 256b datapath, but a 256b VLIW word.

[maitas]

Well, Intel is doing it with Pentium4. I guess you are wright that the OS manages the threads, but in a multiprocessor systems you do have multiplethreads running. That's why IBM Power's shows as two chips for the OS, so they can be fetched a second thread. I guess that with a double register set (as the Pentium 4 does) you can publish yourself as two CPUs, althogh you really as only "one" (parallel Ok) processing unit, but keeps two threads states.

YHBT!

[Anonymous Coward]

See subject.

YHBT!

10 hours+ operation on a C1VP

[stupkid]

I have a Sony C1VP Picturebook with a 667Mhz Transmeta Crusoe TM5600 in it. With the Quad battery pack I get 10+ hours of operation. It is very nice for those all nighters in the datacenter when you don't have a spare socket to plug into or road trips. I love my C1VP and I think that if you need a small system to get work done they are great.

I have done a few power benchmarks on it. Doing continuous kernel recompiles and running updatedb constantly (Maxed out CPU and Maxed out disk I/O) I was able to get 8 hours of operation out of it. I routinely get over 10 hours of use on battery.

A co-worker of mine has a fujitsu lifebook and he has nothing but great things to say about it. It's a bit larger than the picturebook and doesn't have battery as robust as the C1VP, but it is on the smaller end of the laptop spectrum.

Re:the screensavers: nerds or just dorks?

[Anonymous Coward]

I can't wait for the match between India and Pakistan!
I bet it'll go into sudden-death overtime!

Re:32-bits, 64-bits, 256-bits .... what's the limi

[tri44id]

As far back as 1961, the IBM Stretch supercomputer had 64-bit addressing.

In that type of architecture effective addresess were base+index, with the base value (typically 24 bits) embedded in the instruction and the index computed on separately. The Stretch's index registers were 64 bits wide. Addressing was to 64-bit words, not bytes, so the address space was actually 2^72 bytes!

But there was no virtual memory, so the reality was that the programmer had to work with the amount of real memory avaialable, typically 96Kwords (less than 1 megabyte).

Re:32-bits, 64-bits, 256-bits .... what's the limi

[Anonymous Coward]

Except that's not how CPUs are rated.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[Paul Komarek]

Yes and no.

On RISC cpus things are supposed to be simple (by definition). They have a word size which is also the address size and integer size. When someone says "32 bit cpu", they're probably talking about the word size of a RISC cpu. The lab group I work in is mostly interested in large memory attached to a single cpu, hence our desire for a 64 bit address space. I recently needed 64 bit integers for exact arithmetic, but that is the first time that happened for anyone in my lab group.

And a word of caution. A 32 bit RISC cpu has 32 bit memory addresses, but that doesn't mean one can address 2^32 bytes of ram. Modern operating systems use "virtual memory" for a variety of reasons, and one of the side effects is that the virtual memory system "steals" some of those 2^32 addresses, and hence not all 2^32 addresses are available for mapping to physical RAM. There are many other things that "steal" addresses from the address space. In the "simplest" scenario (in some sense), you can only have half as much physical RAM as you have addresses. Thus only 2^31 bytes worth on a 32 bit RISC cpu (2GB).

The folks using the IBM Stretch in the 1960s (thanks to tri44id for his post about this) probably weren't really concerened with having lots of RAM. They were probably more interested in making calculations concerning nuclear tests more accurate. Furthermore, RISC cpus (on the market) didn't show up until the mid 1980s, and saying that the Stretch was a 64 bit computer would be very misleading. Parts of the cpu handled 64 bits "simultaneoulsy", but which parts? You'd have to do some research to find out.

If you're interested in computer history as much or more than computer architecture, I recommend "A History of Modern Computing" by Ceruzzi (curator of the Smithonian's Air & Space Museum). I recommend only glancing at the Introduction, as it is isn't nearly as good as the rest of the book. Overall, I love this book.

-Paul Komarek

Re:32-bits, 64-bits, 256-bits .... what's the limi

[Paul Komarek]

Heh. My TI 99-4/A would have had some mixed-up numbers, too. As would the 8086 cpu from Intel.

The problem here is that we're not talking about RISC cpus, where a word is a word is a word.

-Paul Komarek

oh yeah...

[Sj0]

This is gonna be good.

Between Matrox and Transmeta, It's a very good time to be waiting patiently for processors and video cards, since the next generation looks like it will be sweet!

Profits... no suprise

[degauss]

Well, we have always known that the japeneese are leaps and bounds ahead of us in miniaturization. And since Transmeta's target audience seems to be people who are looking for small, low power apps, of course the japaneese market is going to snap that up.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[Analog Squirrel]

As I recall(it's been a while since I played around with a C64), the C64 got around its 8 bit limit by doing some funky "bank register" stuff so that you were actually selecting between one of 4 16k memory banks... I know this isn't quite right, since even 16K assumes 14 bits... but I do know there was some kind of hoopty-magic going on to make things work...

Re:It's not a 256b datapath, but a 256b VLIW word.

[Anonymous Coward]

A) Because Transmeta is VLIW, they don't speculatively execute. That's the whole point, Instruction Fetch/Decode (two of the bottlenecks in traditional architectures) have been more or less eradicated because it's so simple.

Nothing's been eradicated. The jury is still out on VLIW. It definitely has a lot of potential but real world applications rarely get close to exploiting the full capability of a VLIW chip.

Eight simultaneous instructions might be a big gamble, so hopefully Trasmeta knows what they're doing. Compilers for VLIW processors with that much possibility for parallelism rarely can exploit it. The vast majority of the time, only a few execution units are kept busy and a ton of bandwidth is wasted.

If compilers are having a hard time, dynamic binary translators are going to do even worse because they have to do their job reasonably quickly.

There is a pretty nice VLIW architecture out there; perhaps you've even heard of it. It's called IA-64. Instructions are always issued in bundles (3 instructions per bundle) and multiple bundles which all can be executed in parallel make up a group. There is no fixed length for groups -- they're terminated with a special stop code in one of the bundles' template bits. This avoids tying programs down to a specific implementation of an IA-64 chip and will allow chips to take advantage of really long instruction groups as more execution units are added.

Of course, the initial offerings from Intel in the Itanium family aren't great, but they've got plenty of room for improvement and I'm sure Intel will do whatever it takes to get their chips up to speed. Intel gets slammed a lot, but their technology is a heck of a lot cooler than Transmeta's -- when Transmeta does something wrong (which they have done a lot of), the Slashdot crowd ignores it because Linus works for them. Hypocrites.

B) The translation doesn't have to be that great. They're still performing fairly competitively with Intel chips.

Oh yes it does. The translation has to be _very_ good if you're planning on using it a lot. I don't know how much internal RAM for storing translated code a Transmeta CPU has, but if it doesn't have much, the translation has to be performed quickly. It's a tricky trade-off.

E) Transmeta's solution is so amazing that, even if it hasn't revolutionized the world, it has changed the course of Intel's strategy non-trivially. Plus, it's awesomely cool.

It's not really revolutionary technology. Binary translation has been around for a while. What is cool is that they have it transparently done on a chip, but it's kind of pointless in the long run since you can't (to my knowledge) load up different translators at run time to emulate different chips.

I don't think it's changed Intel's strategy in a massive way. Crusoe is almost a non-issue. The processors don't perform very well and it's not like they're _way_ ahead of Intel in terms of power consumption. Intel isn't going to be beat by Crusoe.

What I want to see is an improved IA-64 offering. Hopefully Itanium 2 will be better than the original. It's got mad potential! The Slashdot crowd should love it -- it's really cool technology if you've bothered to order the programming manuals.

Forget the Mhz war...

[CNERD]

The Mhz war was so yesterday.
Now its the Bit war!

Re:32-bits, 64-bits, 256-bits .... what's the limi

[drinkypoo]

Bits of address space are not, repeat not used as the standard for determining what-bit a CPU is. It's the length of the instructions, AND the length of the GPRs.

For instance: a MC68000 chip is a 16 bit CPU, I think we've all accepted that at some point in our lives. However, it has 24 bit addressing.

Re:32-bits, 64-bits, 256-bits .... what's the limi

[Paul Komarek]

Is the MC68000 considered to be a RISC cpu? If so, I'm surprised about this difference in word size. Is it targetted at some market besides gneeral purpose computing?

-Paul Komarek

Re:32-bits, 64-bits, 256-bits .... what's the limi

[Jay Carlson]

What a great troll. GPRs are a reasonable measure of CPU size; they tend to serve as a proxy for address space as well. But GPRs are the main justification for labeling the 8080 an 8-bit chip, even though you can use HL to address 16 bits of memory.

But instruction size is just silly, and why I think you're trolling. The Athlon in this box uses variable-length instructions; most are 8 bits long. The Alpha, normally considered a 64-bit machine, uses 32-bit instructions. The Itanic puts three instructions into a 128-bit bundle, making its instruction length about 42 bits. The NEC Vr4181 in the Agenda VR3 PDA in my pocket has a 16-bit data bus and modes for both 32- and 64-bit GPRs.

Oh and the Vr4181 has both the standard 32-bit MIPS II instruction set and the 16-bit MIPS16 set, with instructions to switch between them.

From a programmer's point of view the data bus, physical address pins, and the size of instructions are just implementation details. What's important is the instruction set architecture, and the computing model defined by it. In both MIPS II and MIPS16 modes, the Vr4181 has 32-bit GPRs and a flat 32-bit address space. (With a little kernel hacking, it'd be 64-bit GPRs and addressing, but that would be silly.) When I take my code to a Vr4131, which has a 32-bit data bus, I don't have to change anything.

That's why I consider the 68000 to be a 32-bit architecture. Except for performance, my code will run identically on the 68008, 68000, and 68020, with their external 8, 16, and 32 bit data buses.

For the new Transmeta chip, this evaluation strategy says that it's still a 32-bit chip. Programmers outside of Transmeta don't directly program the device, so it makes no difference what the internal ISA is. The externally visible ISA is still the variable-length 8-bit IA-32 architecture, with its 32-bit GPRs. I'd bet they aren't implementing the cheap hacks to get 36-bit physical addressing...

Re:32-bits, 64-bits, 256-bits .... what's the limi

[jd]

A number of 8-bit computers (the CBM PET, the BBC Micro, etc) pulled similar stunts.

The PET was expandable to 256K (not bad, for an 8-bit machine!) but the screen flickered horribly. My guess, based on that observation, was that the technique here was to have a very fast switch flip between banks, with the screen RAM on only one of those banks.

In consequence, you could "see" all 256K, but not all at the same time. You would probably need to go through some intermediate layer, to actually go between pages, for that very reason. There would be no way of telling which layer you meant.

The BBC Micro used a system it called "Sideways ROM/RAM", which (AFAIK) was based on having the lower part of RAM fixed, and the upper part selectable. In other words, it wasn't based on auto-cycling (as with the PET) but required code to do the selecting.

IMHO, the CBM64 (which used an 65x02 processor, and could therefore access 64K of memory directly) didn't have any bank selection, as far as I know. 8-bit processors could access 64K of RAM because they worked in pages. 256 pages of 256 bytes. This is why addresses 0-255 are referred to as "Zero Page". (That is also where a lot of OS-based work was done, as that could be accessed the fastest.)

In other words, 8-bit processors, such as the 65x02, used two words for addresses. The Page, and the Offset, giving you an effective 16-bit address length.

(It's also why the ZX80 only had 256 bytes of RAM, and yet worked surprisingly well. With everything in Zero Page, you had the fastest access possible at all times.)

Re:32-bits, 64-bits, 256-bits .... what's the limi

[drinkypoo]

AFAIK the MC68000 is CISC. It's used everywhere; Embedded systems, palm pilots, et cetera. It was the basis of the original macintosh and amiga computers, which eventually moved on to the 68000's descendants (68010, 020, 030, 040, and 060. The '010 is a very slightly upgraded 68000, which executes some operations in less cycles. The palmpilot uses a motorola dragonball processor, which is based on a 68000 core.)

raises the question, not begs

[Anonymous Coward]

Begging the question has, ironically, nothing to do with begging or questions. It involves an implicit assumption in an argument. For example: "God created the universe because only He could have created something so beautiful and ordered" carries the assumption that the universe is beautiful and ordered.

What you want is "raises the question", or perhaps "this question begs to be asked."

Re:32-bits, 64-bits, 256-bits .... what's the limi

[child_of_mercy]

150 years ago thousands of young men worked from dawn to dusk in the counting houses of the dutch east india company.

they scratched and scribbled and did excatly what a single server can achieve today.

which gives those young men time to go out and get drunk instead.