SI
SI
discoversearch

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.
Technology Stocks : Transmeta (TMTA)-The Monster That Could Slay Intel
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: ComradeBrehznev who wrote (54)1/19/2000 9:17:00 PM
From: Jonathan Edwards  Read Replies (2) of 421
 
I've looked over their architectural description. It seems much more evolutionary than revolutionary - essentially moving the microcode off the chip (and leaving the nanocode in place).

I've been told they plan to keep the nanocode proprietary. It looks to me as though this simply makes them another X86 (and PPC, and maybe others) supplier. Perhaps they have a better product and a more talented design team, but it doesn't look like anything Intel couldn't in principle duplicate (especially since Intel's been working on VLIW for some time now).

To be successful as an X86 clone, you've got to be pin compatible with the Real McCoy (well, one of them anyway - pick your slot/socket/whatever). A concrete example: the X86 has a MOV instruction, which transfers data between the CPU and memory, and IN/OUT instructions, which transfer data between the CPU and an "I/O space". In PCs, most peripherals (and not-so-peripherals like the hard disk controller) are managed using the I/O space. The two kinds of instruction behave almost identically - the only difference is the state of a particular signal on the bus that tells the address decode circuitry on the motherboard whether the reference is to memory or to a peripheral.

Since TransMeta has been demonstrated running (presumably) stock Windows on a (presumably) stock PC, they must have a way to generate this sort of hardware signal (and numerous others) when appropriate. I'd love to find out what they've done in this area. Offhand I can think of two approaches:

1) Dedicate a certain number of pins as configurable inputs/outputs and use the microcode (e.g., X86 translator) to drive them as appropriate. This preserves (or at least in theory could preserve) pin compatibility, but makes the chip less generic than they seem to be claiming it is. It would be a real trick indeed to make the chip hardware sufficiently configurable to mimic an X86 or a PowerPC or a MIPS or a SPARC or ...

2) Put knowledge about the system of which the chip is a part in the microcode software. This is certainly a simpler and more generic approach, but it multiplies the number of distinct sets of microcode you have to write - for example, a TransMeta targeted to PCs and a TransMeta targeted to WinCE devices might need different microcode/part numbers/inventory tracking/etc., whereas both kinds of box use the same real X86...
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  

HomeMailHotSubjectMarksPeopleMarksKeepersSettings
Terms Of UseContact UsCopyright/IP PolicyPrivacy PolicyAbout UsFAQAdvertise on SI
© 2025 Knight Sac Media.  Data provided by Twelve Data, Alpha Vantage, and CityFALCON News