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."
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
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.
Well, do not give up yet. While it may be impossible to run programs in the underlying architecture, nothing says that you can not place a different translation code.
I am still waiting for the day when I will be able to run linux/ppc on my transmeta. (Or perhaps even cooler...being able to switch on demand!)
badness 10000
"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.
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.
The article makes it pretty clear why Linux can't run directly on the Crusoe: Linux expects the hardware to have a virtual memory manager, which the Crusoe doesn't have. Consequently, any port of Linux will need to be running on an emulated memory manager.
As a side note, the Crusoe is also missing native support for certain other helpful features:
*Memory protection -- without that, a segfault can take out the entire OS.
*Running code from user memory -- without this, any application code will need to be piped through the OS to the CPU.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
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