Slashdot Mirror
Transmeta TMS5xxx Reverse Engineered
Richard W.M. Jones writes "This fascinating article, published anonymously, dissects the Transmeta TMS5xxx architecture, revealing how to
access and modify the code-morphing code,
how the instruction set works, and tells why
you won't be able to run Linux directly on this
chip."
Transmeta had a chance to do something interesting and amazing but it really has turned out to be a huge disappointment. They can't even get their processors into mainstream laptops and the power savings these days is negligible compared to modern day Intel stuff like the Centrino or P4-M. They should've went the route Via is taking and produce low-power, cool running processors in the mini-ITX form factor motherboards. Via's EPIA line is very nice, but they're starting to slip with some of the modern faster versions that have added fans onto the heatsink. Where are the modern fanless low power fast processors?
The author asserts that transmetas CMS and microprocessors bear striking similarities to an IBM research project named DAISY. I quote:
While I will not give a full analysis here, it appears that much of Transmeta's work was actually invented by IBM Research in the early 1990s. IBM's Daisy (Dynamically Architected Instruction Set from Yorktown) project [6] is essentially CMS for the PowerPC architecture, and uses a strikingly similar design and implementation, including: * Designing the morph host microarchitecture with the same semantics as the target instruction set (in IBM's case, PowerPC rather than x86) * Translated page cache, using a T-bit buffer to track which user pages are dirty and need re-translation * Explicit memory alias handling, using protected loads and checked stores * Extensive profiling logic to aid in further optimization * Handling of speculatively reordered loads and stores to I/O space
I wonder if this was just a question of similar approaches to similar problems, movement of engineers from IBM research to TMTA or something else.
He also states that CMS appears to have been compiled with a hacked up version of gcc and binutils. Isn't failure to release modifications to GPLed code against the license, or am I missing something? I doubt transmeta would've failed to foresee that, so perhaps they're using a different toolchain. Very interesting, all in all!
"The slave who knows his master's will and does not get ready...will be be beaten with many blows."Luke 12:47-48
Fortunately for Transmeta and its end users, this backdoor is difficult to exploit without the consent of the user, since it does require both x86 kernel level access and in some cases physical access to the machine. However, if you are experienced enough to be reading this, such limitations are unlikely to be a problem.
/. readership :)
Ah, someone who still believes in the
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
until someone comes out with a code morphing solution that turns the crusoe into a sparc/alpha/(insert favourite processor here).
It's likely to be quite hard. Firstly you've got to work out how to do code morphing. Remember it took Transmeta 2 years or so to develop the hardware and software.
Secondly, and more importantly, the TMS5xxx has an architecture which is very closely tied to the x86 architecture. eg - there is a common mapping of registers, and certain instructions in TMS are designed to make it easy to run specifically x86 code. Consider how hard it would be to run 64 bit big endian[1] code, for instance, on a processor designed primarily to run 32 bit little endian code. That's only the start of your problems ...
There are some quite interesting applications if this could be done ... eg: perhaps have
multiple architecture OSes running at the
same time? Have multiple processes running
in a single OS which were compiled for
different architectures?
Rich.
[1] Hope I got my endianness the right way round ...
libguestfs - tools for accessing and modifying virtual machine disk images
OK, you might not be able to port Linux to run directly the bare hardware, but what about porting a simpler, more streamlined, processor emulation to run on the bare hardware, preferably one that Linux has already been ported to. Maybe a Crusoe emulating MIPS running Linux might be a more efficient proposition than a Crusoe emulating IA-32 running Linux. Or perhaps Crusoe->ARM->Linux.
----
Open mind, insert foot.
"Where are the modern fanless low power fast processors?"
Why, they're in Transmeta-powered laptops.
An x86 laptop like Toshiba makes gets about 1.5 - 2 hours of battery life. 3 if you only use things like Word, which let Speedstep and the like kick in. A 17" TiBook gets about 3-4 hours, again dependant on load.
Practically every Transmeta-based x86 laptop gets 5 hours, up to 7 if you're using Word. That is nothing to sneeze at. Fujitsu has an optional battery pack for their laptops which nets you 7 to 9 hours of battery life on their Lifestyle series. True x86 laptops are a joke in comparison.
Naturally, trolls ignore these facts when trolling. If you repeat a lie often enough, some moderators will believe it true enough to mod you up...
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Actually the artical says that you can not run ANY os "Native" on this chip. Linux will run just fine using the same X/86 Code morphing system that runs windows.
What I wonder is could you come up with a more morphing friendly ISA than X86? What about then 68040 ISA? How would that work? ARM maybe?
Even if it is less than practical These chips could be good tools for playing around with new ISAs.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Here is an example of a transmeta cluster.
LANL Transmeta Cluster (PDF Link)
And by cant run on the underlying hardware directly, you mean that you cant run on the bare core of the transmeta chip, as opposed to it's x86 translation layer?
As far as I know Linux runs fine on top of it's translation layer, as the chip was designed to do.
The Ro Factor - Jeep/Linux Weblog
It ends up being not as beneficial as you first think.
Think about it... who makes motherboards for these things? Only one or two people for one or two products. You cant just make it, say, an ultrasparc and expect all of the peripherals to work... especially with a PC bios.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
There's an aspect of the Crusoe and code morphing that I am surprised that Transmeta and some vendor haven't jumped on - the idea of using CMS to simulate hardware.
Consider the Centrino chipset from Intel, specifically the 802.11 part. (Now, this is conjecture on my part, but fits the observed behavior of Intel as a corporation and the Centrino chipset, so if somebody can prove me wrong please do so.)
I suspect the real reason that Intel is uneasy about releasing Linux drivers for the Centrino's WLAN chip is not just that an open source driver could be programmed to operate out of band or over power. I suspect that the WLAN chip is little more than a DMA core and an RF A/D converter (actually, a quadrature programmable up converter)- that the actual modulation/demodulation are being done by the CPU. Were that the case, then releasing the driver would expose a complete 802.11* modulation/demodulation algorithm. Furthurmore, modifications to that code could perform other forms of modulation besides 802.11 - a regulatory nightmare.
Now, consider the Crusoe. What if you had a version of the CMS that emulated a hardware device at a specific set of I/O addresses? The x86 driver would queue a bufferlist of symbols to be modulated, and, from the perspective of the x86 driver, "hardware" would DMA that data, modulate it, and send it. Simillarly, the x86 driver would queue a bufferlist of empty buffers, and "hardware" would receive the data, demodulate it, and fill the buffers.
Now the real work would be done in native CMS micro-ops. The micro-ops would create the modulation buffers from the symbol buffers (storing them into the CMS working area), and would set up the REAL DMA to transfer those modulation buffers to the RF section. Simillarly, the CMS code would set up the RF section to fill buffers in CMS-space with received data, which would then be decoded by the CMS code into symbols and placed into the x86 bufferspace.
The advantage of this is that the x86 drivers for (Windows|Linux|*BSD) would not contain any of the "magic" that causes problems - indeed, the "hardware" could have a register that sets the region the system supposedly is in, allowing the "hardware" (CMS driver) to select power levels, frequencies, and modulation schemes that are permissable to the area (e.g. USA, England, etc.) Thus the drivers could be completely Free.
I would think that this could allow a one-chip-wonder computer - a single Transmeta part for the main system, with integrated video, 802.11, Bluetooth, audio, V.90 modem, etc. Add an RF chip for the RF side of the Bluetooth and 802.11, RAM, a flash-ROM chip, et voila! A very low power, all integrated laptop/PDA/Phone/Set top box/Whatever that could have GOOD driver support under any OS.
(Yes, such a technique would shoot to hell any chance of hard-realtime in the OS, as "hardware" might preempt the code. However, I would not want to do hard real time on a Crusoe anyway, as you simple cannot guarantee the execution time of any block of code due to the possiblity of needing to re-morph it.)
www.eFax.com are spammers
The thing is, if you're giving up x86 compatibility, there's no reason morphing is needed. ARM and PPC run fine without morphing; in modern sparc and mips, maybe you'd want to magic away the delay slots, but they don't really hurt anything... only the baroque CISC architectures gain any significant advantage (even in theory) from morphing.
I've had this sig for three days.
No. They ship the output, which is *not* covered by the GPL.
Forth is a language that has often been put on extremely small and simple die. It seems to me it would be possible to implement it on TMTA technology, especially considering the number of available registers - enough to guarantee the stack won't have to be put in RAM more than 90% of the time, iirc.
:)
ANyone up for this?
Try Corewar @ www.koth.org - rec.games.corewar