Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?

To: Petz who wrote (122845)	8/22/2000 3:13:03 PM
From: Scumbria	Read Replies (1) \| Respond to of 1578324

John, Transmeta's CPU is actually a VLIW engine, rather than RISC. Scumbria

To: Petz who wrote (122845)	8/22/2000 4:14:17 PM
From: tejek	Respond to of 1578324

Petz Thanks for the detailed explanation. The essential concept to understand is that the TM CPU translates x86 code found in your software on the fly into the simpler RISC instruction set of the core CPU (lets call it, "TM code"), but in most cases each x86 instruction is only translated once into "TM code." The translation of x86 code into TM code is not done by a big hardware engine inside the TM CPU, it is done by a software program which once in a while interrupts the execution of already translated code so that it can translate new chunks of code. I take it that this is the way power consumption is reduced substantially. If a program just consisted of a sequence of intructions without any loops, the TM CPU would be extremely inefficient. It would spend a good deal longer translating the program into its little bite size TM instructions than it would take for even a 486 to execute the program. There are some disadvantages to this approach, I've made it sound like a panacea. For one, fast floating point requires a total hardware implementation, and fast FPU's take a lot of power. The Crusoe isn't designed to do floating point super fast. Second, if a program jumps all over the place, then the it is less likely that the translated code will be in the cache, which means that code may have to be re-morphed many times. This would happen, for example, on benchmarks that do a lot of multitasking. Finally, its a poor choice for anything that requires a predicable response time, because, when an how often the execution of a program has to be interrupted to do some more "morphing" is unpredictable. I take it that is why the TM chip is relegated to the low end. PS, see also arstechnica.com; Thanks for the link. ted