Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Transmeta Hardware

Transmeta TMS5xxx Reverse Engineered 53

Posted by timothy from the they're-still-around-y'know dept.
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."
This discussion has been archived. No new comments can be posted.

Transmeta TMS5xxx Reverse Engineered More

Transmeta TMS5xxx Reverse Engineered

Comments Filter:

  • Not interesting anymore (Score:3, Insightful)

    by AKnightCowboy ( 608632 ) on Tuesday February 10, 2004 @07:44AM (#8236254)
    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?
    • 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!)

    • Troll, troll, troll your boat! (Score:5, Interesting)

      by Inoshiro ( 71693 ) on Tuesday February 10, 2004 @09:49AM (#8237126) Homepage
      "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 [fujitsu.com]. 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...
      • "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."

        I have a friend whose Dell Pentium-M powered notebook goes for 4+ hours.

        • Re:Troll, troll, troll your boat! (Score:5, Informative)

          by Experiment 626 ( 698257 ) on Tuesday February 10, 2004 @02:14PM (#8240569)

          Just to elaborate on what RzUpAnmsCwrds said a bit... For modern Intel based laptops, there are basically three levels of of power hunger.

          Lower price laptops use the same CPUs (P4 or Celeron) as desktop PCs. These are great (aside from heat) if you keep them plugged in, but you may only get an hour or two of battery time.

          Then there are the variants that are modified for lower power consumption, P4M / Mobile P4. These turn off some power wasting CPU features and run more power efficiently than desktop chips. These cost a little more but should keep you above two hours on battery life.

          Finally, there is the Pentium-M, better known as Centrino as it is called when bundled with Intel's own chipset and wireless adapter. This is a different architecture, built with low power in mind. Intel basically started with a P3, which were less of a power hog than the P4, and added features to give it lots of processing capacity without making it need so much energy. The Pentium-M runs at a much lower clock rate than the P4, but executes more instructions per clock to compensate, and comes with a large cache. It's a really clever architecture, and you can get at least 4 hours of battery life, 7 if you use a secondary battery.

          I'm not really sure how AMD and Transmeta stack up. Transmeta seems like they are aiming at the market segment that only needs a few hundred MHz instead of a full-blown desktop equivalent, willing to give up speed for low power use. The Pentium-M can be used in "ultra low power" configurations like this, but is most commonly seen in laptops that give a few hours of battery life while keeping performance on par with a desktop.

        • What model does he have? I own a Dell Latitude D600 (Pentium-M 1.6 GHz), and I've been a bit disappointed. I can't get more than 3 hours, even with the CPU running at 600 MHz, the display at low power and the disk spinning down when unused.
      • I tend to abuse laptops, often spending much of my time at very high CPU loads. I used a 15" TiBook and, despite the thing being brand new, only got a little under 2 hours of battery life out of it (a couple of minutes short).

        Perhaps the 17" TiBooks have higher quality batteries in them. I assume they'd need one with considerably more juice than the 15" in order to get close to 4 hours of life.
        • The batteries are roughly the same quality, but of course the bigger laptops have batteries with larger capacities. The iBooks also seem to have the same quality batteries as the alBooks, as far as I can tell.
      • dickface!

        Unfortunately, the processor isn't the only laptop component that uses electricity. And it isn't even the major electricity user!

        TMTA has no power or speed advantage over a low-speed celeron or pentium M, and even more importantly, no price advantage.

        1. hire geek circle-jerk icon Linus Torvaldes
        2. ???
        3. Profit!
  • and tells why you won't be able to run Linux directly on this chip."

    ....Oh! The Irony!

    • Re:what was he THINKING? (Score:5, Informative)

      by LWATCDR ( 28044 ) on Tuesday February 10, 2004 @10:52AM (#8237942) Homepage Journal
      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.
      • Indeed, I've been thinkingn about this even before the article. If the internal model is RISC, why not build a almost similar RISC ISA on top of it, with just the protection stuff and such added. The closer you can bring the emulated ISA to the underlying ISA, the more you should be able to benefit.

        Looking at the article, it doesn't look like x86 was the optimum ISA to emulate. On the other hand, Linus has made some comments on how x86 ISA could actually benefit from having variable-length opcodes since m

      • Re:what was he THINKING? (Score:4, Interesting)

        by addaon ( 41825 ) <addaon+slashdot@nOsPAM.gmail.com> on Tuesday February 10, 2004 @12:11PM (#8239114)
        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.
        • " The thing is, if you're giving up x86 compatibility,"

          Not really. IBM uses something like code morphing for there AS/400 midrange computers. The AS/400 replaced the model 38. The model 38 used an "idealized" instruction set. The model38 used a huge CISC cpu, The AS/400 was based on PPC yet the can run Model 38 software.
          Code morphing allows a yet another layer of abstraction.
          There are other old ISA besides Intels that could continue to live a productive life buy running on code morphing cpus. The 680XX whe
          • Except that all the cisc chips you mention can be easily emulated (and some can be simulated effectively!) on any modern risc or cisc chip. Java bytecode runs just fine on custom hardware, but isn't too well suited for morphing; if you're running on hardware, you might as well use a real stack machine. x86 is the only cisc instruction set that's within a factor of ten or so of the performance of the leading processors (actually, it's within a factor of one).
        • Of course there is, if the transmeta-cpu is less powerhungry than the ppc/mc680x0/arm-cpu it's emulating.
          And it would be really cool to have a cpu that could *change* while running, so that you could be running MacOSX on PPC-emulation and start x86-programs that runs x86-emulation.
          Even if it would take a reboot to change architecture and then boot into a different os, it would be really cool. =)
          I would love to have a machine capable of running IRIX, WinXP, MacOSX, Mac classic just by rebooting.
          Of course, it

  • TMTA, IBM research, and gcc/binutils (Score:5, Interesting)

    by aurum42 ( 712010 ) on Tuesday February 10, 2004 @07:59AM (#8236322)
    Several interesting questions raised by the article:

    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!

  • until someone comes out with a code morphing solution that turns the crusoe into a sparc/alpha/(insert favourite processor here).

    So what if the rest of the hardware will be peecee, it'd still be some fun.

    • Re:How long... (Score:5, Interesting)

      by Richard W.M. Jones ( 591125 ) <rich@anne[ ].org ['xia' in gap]> on Tuesday February 10, 2004 @08:09AM (#8236387) Homepage

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

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

  • Are *you* experienced? (Score:5, Funny)

    by DrSkwid ( 118965 ) on Tuesday February 10, 2004 @08:04AM (#8236357) Journal
    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.

    Ah, someone who still believes in the /. readership :)

  • Cripes, your laptop broadcasts the whole frikkin pipeline!

    Write: Write results back to GPRs or store buffer

  • Linux on a Transmeta (Score:5, Interesting)

    by Gleef ( 86 ) * on Tuesday February 10, 2004 @09:05AM (#8236771) Homepage
    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.
    • Then you have to rewrite the whole translation system. I'd guess it's a *huge* job. At least if you want the resulting CPU to run faster than an x86 (that has been optimized by the Transmeta engineers).
  • What is this chip and who uses it? =/

  • None shall pass! (Score:3, Funny)

    by alexjohns ( 53323 ) <almuric.gmail@com> on Tuesday February 10, 2004 @09:43AM (#8237065) Journal
    "...and tells why you won't be able to run Linux directly on this chip."
    A whole bunch of kernel hackers just got slapped across the face with a silk glove, I do believe.

    • Re:None shall pass! (Score:4, Interesting)

      by Carnildo ( 712617 ) on Tuesday February 10, 2004 @04:49PM (#8242299) Homepage Journal
      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.

  • Centrino style chipsets (Score:5, Interesting)

    by wowbagger ( 69688 ) on Tuesday February 10, 2004 @11:29AM (#8238448) Homepage Journal
    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.)

  • Great Scott! (Score:1, Redundant)

    by stuffduff ( 681819 )
    Now that it's shown that TransMeta may have borrowed from IBM, how long until SCO makes claims against it!

  • Forth Chip (Score:2, Interesting)

    by pkhuong ( 686673 )
    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? :)
  • The processor has 64 GPRs, with the following specialized semantics: * %r63 (%zero) always reads 0 when used as a source operand * %r62 (%sink) is a discarded destination (e.g., for compares); it is never read

    Wow. /dev/zero and /dev/null in silicon.

Slashdot Top Deals

"How to make a million dollars: First, get a million dollars." -- Steve Martin

Close