Editing Transmeta (section)

==Technology==
{{refimprove section|date=March 2014}}
Transmeta processors were in-order [[very long instruction word]] (VLIW) cores running a special dynamic binary translation software layer which together implemented compatibility with the x86 architecture. Transmeta trademarked the term "Code Morphing" to describe their technology<ref>[http://news.zdnet.com/2100-9595_22-525936.html "Code-morphing: Fresh as a DAISY"] {{webarchive |url=https://web.archive.org/web/20080605150435/http://news.zdnet.com/2100-9595_22-525936.html |date=June 5, 2008 }} by Mary Foley</ref> and referred to the software layer as Code Morphing Software (CMS).

Transmeta used [[reverse body bias]] to reduce power used by a factor of about 2.5. (A similar technology was used in [[XScale]] processors.)<ref name="DietrichHaase2011">{{cite book|author1=Manfred Dietrich|author2=Joachim Haase|title=Process Variations and Probabilistic Integrated Circuit Design|url=https://books.google.com/books?id=43SdFYKJ47gC&pg=PA185|year=2011|publisher=Springer|isbn=978-1-4419-6621-6|page=185}}</ref>

===Code Morphing Software===
'''Code Morphing Software''' ('''CMS''') is the technology used by Transmeta microprocessors to execute [[x86]] instructions.<ref name="cms">[http://www.ptlsim.org/papers/transmeta-cgo2003.pdf The Transmeta Code Morphing Software: Using Speculation, Recovery, and Adaptive Retranslation to Address Real-Life Challenges] {{webarchive|url=https://web.archive.org/web/20081204122100/http://www.ptlsim.org/papers/transmeta-cgo2003.pdf |date=2008-12-04 }} -  Appeared in the Proceedings of the First Annual IEEE/ACM International Symposium on Code Generation and Optimization, 27–29 March 2003, San Francisco, California</ref>
<ref name="scopes2003">[http://www.xsim.com/papers/transmeta-scopes-2003.dehnert.pdf Transmeta Crusoe and Efficeon: Embedded VLIW as a CISC Implementation]
{{webarchive|url=https://web.archive.org/web/20180107230752/http://www.xsim.com/papers/transmeta-scopes-2003.dehnert.pdf |date=2018-01-07}} - Appeared in the proceedings of SCOPES, Vienna, 25 September 2003</ref>
In broad view, CMS reads x86 instructions and generates instructions for a proprietary [[VLIW]] processor, in the style of Shade.<ref name="shade">[http://www.cs.washington.edu/research/compiler/papers.d/shade.html Shade]{{webarchive|url=https://web.archive.org/web/19990429153111/https://www.cs.washington.edu/research/compiler/papers.d/shade.html |date=1999-04-29}}</ref>
CMS translation is much more expensive than Shade's, but produces much higher quality code. CMS also contains an interpreter and simulates both user-mode and system mode operation.

Code Morphing Software consisted of an [[Interpreter (computing)|interpreter]], a [[runtime system]] and a [[Binary translation#Dynamic binary translation|dynamic binary translator]]. [[x86]] instructions were first interpreted one instruction at a time and profiled, then depending upon the frequency of execution and other [[heuristic (computer science)|heuristics]], CMS would progressively generate more optimized translations.<ref name="Tech_Behind_Crusoe"/><ref name="Exper_With_DBT"/><ref name="TMTA_Code_Morph_SW"/>

Similar technologies existed in the 1990s: [[Wabi (software)|Wabi]] for [[Solaris (operating system)|Solaris]] and [[Linux]], [[FX!32]] for [[DEC Alpha|Alpha]] and [[IA-32 Execution Layer|IA-32 EL]] for [[Itanium]], open-source DAISY,<ref>{{cite web|url=http://www.research.ibm.com/daisy/ |title=DAISY: Dynamically Architected Instruction Set from Yorktown |publisher=Research.ibm.com |access-date=November 13, 2011}}</ref> the [[Mac 68K emulator]] for the PowerPC.{{citation needed|date=November 2013}} The Transmeta approach set a much higher bar for x86 compatibility due to its ability to execute '''all''' x86 instructions from initial boot up to the latest multimedia instructions.

The operation of Transmeta's code morphing software is similar to the final optimization pass of a conventional compiler. Considering a fragment of 32-bit x86 code:

 add eax,dword ptr [esp] // load data from stack, add to eax
 add ebx,dword ptr [esp] // ditto, for ebx
 mov esi,[ebp]           // load esi from memory
 sub ecx,5               // subtract 5 from ecx register

This is first converted simplistically into native instructions:

 ld %r30,[%esp]       // load from stack, into temporary
 add.c %eax,%eax,%r30 // add to %eax, set condition codes.
 ld %r31,[%esp]
 add.c %ebx,%ebx,%r31
 ld %esi,[%ebp]
 sub.c %ecx,%ecx,5

The optimizer then eliminates common sub-expressions and unnecessary condition code operations and, potentially, applies other optimizations such as [[loop unwinding|loop unrolling]]:

 ld %r30,[%esp]     // load from stack only once
 add %eax,%eax,%r30
 add %ebx,%ebx,%r30 // reuse data loaded earlier
 ld %esi,[%ebp]
 sub.c %ecx,%ecx,5  // only this last condition code needed

Finally, the optimizer groups individual instructions ("atoms") into long instruction words ("molecules") for the underlying hardware:

 ld %r30,[%esp];  sub.c %ecx,%ecx,5
 ld %esi,[%ebp];  add %eax,%eax,%r30;  add %ebx,%ebx,%r30

These two VLIW molecules could potentially execute in fewer cycles than the original instructions could on an x86 processor.<ref name="Tech_Behind_Crusoe"/>

Transmeta claimed several technical benefits to this approach:
# As the market leaders [[Intel Corporation|Intel]] and/or [[Advanced Micro Devices|AMD]] would extend the core x86 instruction set, Transmeta could quickly upgrade their product with a software upgrade rather than requiring a respin of their hardware.
# Performance and power can be tuned in software to meet market needs.
# It would be relatively simple to fix hardware design or manufacturing flaws in the hardware using software [[workaround]]s.
# More time could be spent concentrating on enhancing the capabilities of the core or reducing its power consumption without worrying about [[List of Intel microprocessors|33 years of backward compatibility]] to the x86 architecture.
# The processor could emulate multiple other architectures, possibly even at the same time. (At its initial Crusoe launch, Transmeta demonstrated [[pico-Java]] and x86 running intermixed on the native hardware.)

Prior to Crusoe's release, rumors indicated Transmeta was relying on these benefits to develop a hybrid [[PowerPC]] and x86 processor. But Transmeta would initially concentrate solely on the extremely low-power x86 market.

The ability to quickly update products without a hardware respin was demonstrated in 2002 with an in-the-field upgrade (a download) to enhance CPU performance of the [[Transmeta Crusoe|Crusoe]] based [[Compaq TC1000|HP Compaq TC1000]] tablet PC. It was used again in 2004 when [[NX bit]] and [[SSE3]] support were added to the [[Transmeta Efficeon]] product line without requiring hardware changes. In the field upgrades were rare in practice due to system hardware vendors not wanting to incur additional customer support costs or spend additional money on QA for the potential upgrades or bug fixes to shipped products they had already closed the revenue books on.

===VLIW core===
In conjunction with its code-morphing software the Efficeon most closely mirrors the feature set of [[Intel]] [[Pentium 4]] processors, although, like [[AMD]] [[Opteron]] processors, it supports a fully integrated [[memory controller]], a [[HyperTransport]] IO bus, and the [[NX bit]], or no-execute [[x86]] extension to [[Physical Address Extension|PAE mode]]. [[NX bit]] support is available starting with CMS version 6.0.4.

Efficeon's computational performance relative to mobile CPUs like the [[Intel]] [[Pentium M]] is thought to be lower, although little appears to be published about the relative performance of these competing processors.

Efficeon came in two package types: a 783- and a 592-contact [[ball grid array]]. Its power consumption was moderate (with some consuming as little as 3 watts at 1&nbsp;GHz and 7 watts at 1.5&nbsp;GHz), so it could be passively cooled.

Two generations of this chip were produced. The first generation (TM8600) was manufactured using a [[TSMC]] 130&nbsp;nm process and produced at speeds up to 1.1 [[GHz]]. The second generation (TM8800 and TM8820) was manufactured using a Fujitsu 90&nbsp;nm process and produced at speeds ranging from 1&nbsp;GHz to 1.7&nbsp;GHz.

Internally, the Efficeon had two [[arithmetic logic unit]]s, two load/store/add units, two execute units, two [[floating-point]]/[[MMX (instruction set)|MMX]]/[[Streaming SIMD Extensions|SSE]]/[[SSE2]] units, one [[branch predictor|branch prediction unit]], one alias unit, and one control unit. The VLIW core could execute a 256-bit VLIW instruction per cycle. A VLIW is called a molecule and has room to store eight 32-bit instructions (called atoms) per cycle.

The Efficeon had a 128-KB L1 instruction cache, a 64-KB L1 data cache and a 1-MB L2 cache. All caches were on die.

Additionally, Efficeon code morphing software (CMS) reserved a small portion of main memory (typically 32 MB) for its cache of dynamically translated x86 instructions.

===Native compilation===
In principle, it should be possible to optimize x86 code to favor [[Code Morphing Software]], or even for compilers to target the native [[VLIW]] architecture directly. However, writing in 2003, [[Linus Torvalds]] apparently dismissed these approaches as unrealistic:<ref>{{cite web|url=http://marc.info/?l=linux-kernel&m=105606848227636&w=2 |title=Linus Torvalds writing in the linux-kernel mailing list |publisher=Marc.info |date=June 20, 2003 |access-date=November 13, 2011}}</ref><ref>{{cite web|url=http://marc.info/?l=linux-kernel&m=105612366806449&w=2 |title=Linus Torvalds writing in the linux-kernel mailing list |publisher=Marc.info |date=June 20, 2003 |access-date=November 13, 2011}}</ref>

{{quote|The native crusoe code – even if it was documented and available – is not very conducive to general-purpose OS stuff. It has no notion of memory protection, and there's no MMU for code accesses, so things like kernel modules simply wouldn't work.

The translations are usually better than statically compiled native code (because the whole CPU is designed for speculation, and the static compilers don't know how to do that), and thus going to native mode is not necessarily a performance improvement.

So no, it wouldn't really benefit from it, not to mention that it's not even an option since Transmeta has never released enough details to do it anyway. Largely for simple security concerns – if you start giving interfaces for mucking around with the "microcode", you could do some really nasty things.

[...I meant...] "you cannot do that". And we won't even tell the details of how you cannot do that.

In fact, even inside transmeta you cannot do that, without having a specially blessed version of the flash that allows upgrades. If you ever see a machine with a prominent notice saying "CMS upgraded to development version", then that's a hint that it's a machine that TMTA developers could change.|Linus Torvalds|''linux-kernel mailing list''}}

Subsequent [[reverse engineering]], published in 2004, clarifies some details of the native VLIW architecture and associated instruction set, and suggests that there are fundamental limitations that preclude porting an operating system such as Linux to it.<ref name="RealWorldTechnologiesCrusoeExposedI">{{cite web|author=Real World Technologies |url=http://www.realworldtech.com/crusoe-intro/ |title=Real World Technologies – Crusoe Exposed: Reverse Engineering the Transmeta TM5xxx Architecture I |publisher=Realworldtech.com |access-date=November 13, 2011}}</ref><ref name="RealWorldTechnologiesCrusoeExposedII">{{cite web|author=Real World Technologies |url=http://www.realworldtech.com/crusoe-exposed/ |title=Real World Technologies – Crusoe Exposed: Reverse Engineering the Transmeta TM5xxx Architecture II |publisher=Realworldtech.com |date=January 27, 2004 |access-date=November 13, 2011}}</ref>

The same work also compares Transmeta's patented technology with prior art published and in some cases patented by IBM, and suggests that some claims might not stand detailed scrutiny.<ref name="RealWorldTechnologiesCrusoeExposedII" />