3. Die Code-Morphing-Software - TU Bergakademie Freiberg

Der Transmeta Crusoe
Prozessor
Ausarbeitung zum Vortrag im Seminar: Projekte der Informatik WS 04/05
an der TU-Bergakademie Freiberg
Dirk Bräuer
Januar 2005
1

Inhaltsverzeichnis
1. Einleitung......................................................................................................................................... 6
1.1 Die Firma Transmeta................................................................................................................. 6
1.2 Der Crusoe Prozessor.................................................................................................................7
2. Der Aufbau des Crusoe Prozessors.................................................................................................. 8
3. Die Code-Morphing-Software (CMS)............................................................................................11
3.1 Einleitung.................................................................................................................................11
3.2 Befehlsverarbeitung................................................................................................................. 11
3.3 Struktur.................................................................................................................................... 13
4. Hardwareunterstütrzung für Code Morphing Software..................................................................16
4.1 Ausnahmebehandlung..............................................................................................................16
4.2 Alias Hardware........................................................................................................................ 16
4.3 Selbstmodifizierender Code.....................................................................................................18
4.3.1 Einleitung......................................................................................................................... 18
4.3.2 Fine Grain Protection....................................................................................................... 18
4.3.3 Self Revalidating Translations......................................................................................... 18
4.3.4 Self Checking Translation................................................................................................19
4.3.5 Stylized SMC................................................................................................................... 19
4.3.6 Translation Groups...........................................................................................................20
5. LongRun Power Management........................................................................................................ 21
5.1 Einleitung.................................................................................................................................21
5.2 LongRun Fähigkeiten...............................................................................................................22
5.3 LongRun Funktionsweise........................................................................................................ 23
5.4 Weitere LongRun Leistungen.................................................................................................. 23
6. Zusammenfassung.......................................................................................................................... 25
2

Abbildungsverzeichnis
Abbildung 1: Firmensitz.......................................................................................................................6
Abbildung 2: TM3120 & TM5400.......................................................................................................7
Abbildung 3: Schichtenaufbau des Crusoe...........................................................................................8
Abbildung 4: Temperatur TM5400...................................................................................................... 8
Abbildung 5: Temperatur Pentium II................................................................................................... 8
Abbildung 6: Hardwaredesign TM5400...............................................................................................9
Abbildung 7: Hardwaredesign TM3120.............................................................................................10
Abbildung 8: CMS - Startup...............................................................................................................11
Abbildung 9: Molekülkombinationen................................................................................................ 12
Abbildung 10: Pipelinestruktur.......................................................................................................... 12
Abbildung 11: Befehlsverteilung verschiedener Architekturen......................................................... 13
Abbildung 12: Flussdiagramm der CMS............................................................................................14
Abbildung 13: Beispiel einer schrittweisen Übersetzung...................................................................15
Abbildung 14: Beispiel Alias Hardware.............................................................................................17
Abbildung 15: Ablauf Alias Hardware...............................................................................................17
Abbildung 16: Falsches Aliasing........................................................................................................17
Abbildung 17: Beispiel Stylized SMC............................................................................................... 19
Abbildung 18: Lineares Power Management..................................................................................... 21
Abbildung 19: LongRun Power Management....................................................................................22
Abbildung 20: LongRun im Vergleich...............................................................................................22
Abbildung 21: Integrierte Northbridge...............................................................................................24
3

Tabellenverzeichnis
Tabelle 1: Crusoe Prozessoren............................................................................................................. 7
Tabelle 2: Compilerähnliche Optimierungen..................................................................................... 14
Tabelle 3: Power Management Technologien.................................................................................... 21
4

Abkürzungsverzeichnis
ACPI Advanced Configuration and Power Interface
ALU Arithmetic Logical Unit
AMD Advanced Micro Devices
APM Advanced Power Management
BIOS Basic Input/Output System
CMS Code Morphing Software
DDR-SDRAM Double Data Rate Synchronous Dynamic Random Access Memory
DVD Digital Versatile Disc / Digital Video Disc
FPU Floating Point Unit
I/O Input/Output
LTX LongRun Thermal Extension
MMX Multi Media Extension
PC Personal Computer
PCI Peripheral Component Interconnect
PLL Phase Lock Loop
RISC Reduced Instruction Set Computing
ROM Read-Only-Memory
SMC Self Modifying Code
VIA Very Innovative Architecture
VLIW Very Long Instruction Word
5

1. Einleitung
1.1 Die Firma Transmeta
Die Firma Transmeta (Abbildung 1) wurde im Jahre 1995 in Santa Clara Kalifornien, einen Steinwurf von Intel entfernt,
gegründet. Wesentliche Beteiligung an dieser Gründung hatten unter anderem David Ditzel, ein ehemaliger Mitarbeiter
von Sun Microsystems, sowie Douglas Laird. Nicht zuletzt aus Werbegründen wurde Linus Torvalds 1997 ins Team
aufgenommen. Jedoch verließ er nach fünf Jahren die Firma um sich der Weiterentwicklung des Linux Kernels zu
widmen. [7], [10]
Knapp fünf Jahre nach der Gründung brachte die Firma im Januar 2000 ihre erste Prozessorfamilie, die Crusoe
Prozessoren, auf den Markt. Nur zwölf Monate später erfolgte der Börsengang. Nach einer weiteren Entwicklungszeit
wurde im Oktober 2003 der Efficeon Prozessor als Nachfolger des Crusoes vorgestellt. [7]
Mit seinen 296 Beschäftigten (Stand 2003) gilt Transmeta, im Vergleich zu den anderen Prozessorherstellern, als sehr
kleine Firma. So musste auch die eigentliche Produktion der Prozessoren ausgelagert werden. IBM übernahm diese
Aufgabe und fertig in seinen Werken Transmetas Produkte. [10]
Im 3. Quartal 2004 konnte die Firma einen Umsatz von 7 Mio. US$ verbuchen. Dies stellt ein Plus von 159% zum
Vorjahr dar. Jedoch steht diesen Zahlen die Summe von 27.5 Mio US$ Verlust im gleichen Quartal gegenüber. Diese
Zahlen lassen vermuten, dass das große Ziel, AMD beziehungsweise Intel Konkurrenz zu machen, bisher unerreichbar
ist. Mit einem Marktanteil von 0.8% liegt Transmeta deutlich hinter den langjährigen Herstellern (AMD: 17.7%,
Intel: 82.5%). Lediglich VIA mit 1% Marktanteil ist in Reichweite. [10]
Große Hoffnung diese Zahlen weiter zu steigern macht der neue 90nm Efficeon Prozessor.
Abbildung 1: Firmensitz
6

1.2 Der Crusoe Prozessor
Die Entwicklung des Crusoe Prozessors begann zeitgleich mit der Firmengründung. Über die gesamte Entwicklungszeit,
wurden keine Informationen nach außen abgegeben. Es machte sich die Redewendung vom Mysterium Transmeta breit.
Die einzigen Gerüchte die kursierten besagten etwas über die Entwicklung eines schnellen RISC-Prozessors.
Am 19. Januar 2000 wurden schließlich zwei Prozessoren vorgestellt: Der TM3120 sowie der TM5400
(Abbildung 2).
Es handelt sich hierbei um VLIW-Prozessoren (Very Long Instruction Word), welche mit einer speziellen Code-
Morphing Software (CMS) ausgestattet sind. Eine weitere Besonderheit stellt der Verbrauch von lediglich 1W unter
Volllast dar. Im Vergleich verbraucht ein Mobile PIII 10W. Um einen weiteren Vorsprung im mobilen Sektor zu
erreichen wurde im TM5400 zusätzlich eine neue Art von Power-Management, das LongRun Power-Management,
implementiert. Dieses ermöglicht eine automatische Softwareregelung von Takt und Spannung.
Die beiden Prozessoren kosteten mit 65$ (TM3120) beziehungsweise 119$ (TM5400) nur einen Bruchteil der anderen
auf dem Markt vertretenen. [7]
In der folgenden Tabelle 1 sollen die einzelnen Crusoe Prozessoren kurz mit den wichtigsten Daten genannt werden.
[11]
Bezeichnung Erschienen Takt L1-Cache L2-Cache
TM3120 9. Jan 2000 333,366,400 MHz 96 KB -
TM5400 9. Jan 2000 500-700 MHz 128 KB 256 KB
TM5600 7. Okt 2000 300-600 MHz 128 KB 256 KB
TM5500 25. Jun 2001 300-800 MHz 128 KB 256 KB
TM5800 25. Jun 2001 300-1000 MHz 128 KB 512 KB
TM5700 5. Jan 2004 667 MHz 128 KB 256 KB
TM5900 5. Jan 2004 800-1000 MHz 128 KB 512 KB
Tabelle 1: Crusoe Prozessoren
Abbildung 2: TM3120 & TM5400
7

2. Der Aufbau des Crusoe Prozessors
Der Crusoe Prozessor ist ein sogenannter Hybrid Prozessor. Dass bedeutet, er ist zum Teil in Hard- und zum Teil in
Software implementiert. Beim Crusoe ist die Aufteilung circa ¼ Hardware und ¾ Software.
Zum Hardwareteil gehört allein der VLIW-Kern mit seinen Schnittstellen. Die Software unterteilt sich in die Code
Morphing Software und dem streng mit ihr verbundenen LongRun Power Management.
Die Vorteile dieser Architektur liegen auf der Hand. Durch die Verwendung von Software werden Transistoren
eingespart. Dies ermöglicht wiederum eine Einsparung von Strom und somit können Akkus von Notebooks längere
Laufzeiten bieten. Ebenso ist die Wärmeabgabe verringert, was die Verwendung von passiven und somit leisen
Kühlsystemen gestattet. [1], [4], [7]
Abbildung 3 zeigt den angesprochenen Aufbau des Prozessors.
Abbildung 3: Schichtenaufbau des Crusoe
Die Abbildungen 4 und 5 zeigen die unterschiedliche Wärmeabgabe eines TM5400 und eines Pentium III, bei der DVD
Wiedergabe. Die Werte sprechen deutlich für Transmeta. Jedoch bleiben die genauen Bedingungen für diesen Test
verborgen. Ebenso wäre der Mobile PIII sicherlich ein besserer Konkurrent gewesen. [1]
Abbildung 4: Temperatur TM5400 Abbildung 5: Temperatur Pentium II
8

Abbildung 6 zeigt das Hardwaredesign des TM5400, welches im folgenden Abschnitt näher erläutert werden soll.
Der Prozessor besitzt fünf Funktionseinheiten: zwei ALUs für Operationen mit ganzen Zahlen, eine FPU/Multimedia
Einheit, welche für Gleitkommaoperationen zuständig ist sowie Befehle des MMX Befehlssatzes unterstüzt. Weiterhin
ist eine Load/Store Unit für Speicherzugriffe sowie eine Branch Unit für Sprungvorhersagen vorhanden.
Jede der ALUs hat Zugriff auf 32 General Purpose Registers, 48 dieser gesamt 64 Register sind zusätzlich in so
genannten Shadow Registern gespiegelt. Ähnlich verhält es sich mit den 32 Floating Point Registern von denen 16
gespiegelt sind. Diese Shadow Register umfassen die x86 Zustände des Prozessors. Ihre nähere Bedeutung wird in
Kapitel 4 erläutert.
Eine weitere Besonderheit stellen der Gated Store Buffer, der Translation-Bit Buffer und die Alias Hardware dar. Sie
dienen wie die Shadow Register der Ausnahmebehandlung des Prozessors und werden ebenfalls in Kapitel 4 näher
erläutert.
Abbildung 6: Hardwaredesign TM5400
Die Schnittstelle für das LongRun Power Management ist ebenfalls in den Kern eingebunden.
Es ist zu erkennen das der Crusoe eine integrierte Northbridge besitzt. Diese bietet neben einer Standard und DDR-
SDRAM Unterstützung eine 32Bit, 33MHz PCI Interface.
Die weiteren Komponenten sind ähnlich denen eines x86 Prozessors und sollen deshalb nicht näher erläutert werden.
9

In Abbildung 7 ist zum Vergleich das Hardwaredesign des TM3120 dargestellt. In den wesentlichen Komponenten
besteht kein Unterschied zum größeren Modell. Das Bild dient der Vollständigkeit.
Die erkennbaren Unterschiede sind der geringere Cache, die fehlende DDR-SDRAM Unterstützung sowie das fehlende
LongRun Power Management Interface. [4]
Abbildung 7: Hardwaredesign TM3120
10

3. Die Code-Morphing-Software (CMS)
3.1 Einleitung
Das Herz des Crusoe Prozessors liegt in der Code-Morphing-Software. Sie stellt einen dynamischen Übersetzer dar,
welcher Instruktionen einer fremden Architektur in die Eigene übersetzt. Die Software ist in einem 512KB Flash-ROM
Speicher abgelegt und wird beim Booten in den Hauptspeicher expandiert, wo sie 2MB Speicherplatz belegt. Sie stellt
die einzige für den VLIW-Kern geschriebene Software dar. Im Wesentlichen wird sie für die Übersetzung von x86
Instruktionen verwendet, wobei jedoch die Übersetzung anderer Architekturen ebenso denkbar ist (Übersetzen von Java
Byte Code wurde bereits demonstriert). Zur Unterstützung stehen ihr 4-14MB Translation Cache zur Verfügung, welche
vom Hauptspeicher des PCs abgezweigt werden.
Mit diesem System ist es möglich veränderte Architekturen durch ein Flash Update auf dem Prozessor lauffähig zu
machen. Ebenso können eventuelle Fehler der Architektur behoben werden. [1], [4], [6], [7]
3.2 Befehlsverarbeitung
Um den Übersetzungsvorgang näher zu betrachten, ist es zunächst notwendig die VLIW Befehle näher zu untersuchen.
Sie haben eine Bandbreite von 64Bit beziehungsweise 128Bit und umfassen damit zwei oder vier einzelnen Befehle,
welche von Transmeta als Atome bezeichnet werden. Die Bündel dieser Befehle werden Moleküle genannt. Alle Atome
innerhalb eines solchen Moleküls werden parallel ausgeführt. Voraussetzung dafür ist, dass die entsprechende Anzahl an
Funktionseinheiten vorhanden ist. [1]
512kByte
FlashROM
CMS
Decompress
2 MBytes of
Crusoe Code
14 MByte of
Crusoe data
Abbildung 8: CMS - Startup
8 KB Crusoe
Local Ins Mem
8 KB Crusoe
Local Data Mem
Durch diese Einschränkung bleiben insgesamt sechs Molekülvarianten übrig, welche in Abbildung 9 dargestellt sind.
Es gibt zwei Moleküle mit vier Atomen und vier Moleküle mit jeweils zwei Atomen. Spezielle Bits ermöglichen die
Unterscheidung der einzelnen Moleküle und damit die richtige Verteilung auf die einzelnen Funktionseinheiten.
Alle Moleküle enthalten ein sogenanntes Commit Flag, dessen Bedeutung in der Ausnahmebehandlung liegt. [4]
11

Ein weiterer Aspekt der Molekülverarbeitung stellen die Pipelines dar (Abbildung 10). Ihre Länge ist um einiges kürzer,
als bei vergleichbaren Prozessoren (Pentium IV: 20 Stufen). Ansonsten sind die wesentlichen Funktionen einer
herkömmlichen Pipeline integriert. [4]
Abbildung 9: Molekülkombinationen
Abbildung 10: Pipelinestruktur
In Abbildung 11 soll nun noch einmal der Unterschied in der Befehlsverwaltung zwischen x86, einem herkömmlichen
VLIW Prozessor sowie dem Crusoe Prozessor dargestellt werden. Beim x86 erfolgt die Aufteilung auf einzelnen
Funktionseinheit durch Prozessorhardware (Instruction Scheduler).
Beim VLIW-Prozessor ist es für den Compiler bereits notwendig die vorhanden Funktionseinheiten zu kennen. Auf
dieser Basis werden die Befehle bereits beim Übersetzen aufgeteilt.
12

Der Crusoe arbeitet nach einem ähnlichen Prinzip. Da jedoch die Übersetzung Just In Time erfolgt, gilt dies auch für die
Verteilung der Befehle. In diesem Fall wird sie von der Code-Morphing-Software übernommen. [4], [9]
3.3 Struktur
x86 VLIW
Crusoe
Abbildung 11: Befehlsverteilung verschiedener Architekturen
Die Code-Morphing-Software besteht aus einem Interpreter und einem Translator.
Der Interpreter führt die x86 Instruktionen In-Order aus, damit sind sowohl geordnete Speicherzugriffe als auch eine
präzise Reproduktion von Fehlern möglich. Während der Ausführung werden Informationen über den Code gesammelt.
Diese Informationen geben Aufschluss darüber, wie häufig ein Codeblock durchlaufen wird, zu welchem Pfad bei
bedingten Sprüngen häufiger verzweigt wird und wann memory-mapped-I/O Operationen verwendet werden. Dieses
Sammeln geschieht im Gegensatz zu einem Software-Profiler während der Ausführung. Damit passt sich der Prozessor
optimal an den Benutzer an.
Diese Art der Befehlsverarbeitung ist sehr langsam, dass heisst es werden mindestens 12 Takte je x86 Befehl benötigt.
Wird ein Codeblock wiederholt aufgerufen (circa 50 mal), so wird seine Adresse zum Translator geschickt. [3]
Der Translator wählt nun einen Bereich um diese Adresse herum aus. Dieser Bereich wird schrittweise in VLIW Code
übersetzt. Zunächst dekodiert das frontend die Befehle und übersetzt sie in Atome. Anschliessend führt der optimizer
bestimmt Compilerähnliche-, x86-spezifische oder VLIW-spezifische Optimierungen durch. Bevor im dritten Schritt der
scheduler die Atome zu Molekülen zusammenfasst.
Der übersetzte Block wird im Translation Cache abgelegt und bis zur eventuellen Neuübersetzung aus diesem heraus
ausgeführt. Ein solcher Codeblock kann bis zu 200 x86 Instruktionen umfassen. [3]
In Abbildung 12 ist das Flussdiagramm der CMS dargestellt. Eine Befehlsfolge trifft zunächst auf den Interpreter.
Dieser untersucht ob das Ausführungslimit bereits überschritten wurde. Ist dies nicht der Fall so interpretiert er den
entsprechenden Befehl, andernfalls wird die Adresse zum Translator übergeben. Dieser übersetzt den Code, speichert
ihn im Translation Cache und führt ihn von dort aus. Verweist ein Sprung innerhalb dieses Blocks auf einen anderen, so
wird dieser als Kette aus dem Cache heraus ausgeführt (Chain). Nach dem die Instruktion interpretiert oder aus dem
13

Translation Cache heraus ausgeführt wurde, wird überprüft, ob sich der nächste Codeblock ebenfalls bereits im
Translation Cache befindet. Ist dies der Fall, so wird er von dort aus ausgeführt. Andernfalls übernimmt der Interpreter
seine Verarbeitung.
Eine Besonderheit stellt der Fall dar, bei dem es während der Ausführung zu einer Exception (Ausnahme) kommt. Dies
kann durch herkömmliche Fehler wie Page Fault oder Division durch 0, durch Interrupts oder aufgrund der Übersetzung
ausgelöst werden. [3]
Interpreter
not
found
Start
exceeded
translation
Threadhold?
find next
instruction
in Tcache?
Abbildung 12: Flussdiagramm der CMS
Die einzelnen Möglichkeiten zur Optimierung sollen im Folgenden kurz erläutert werden. Zunächst werden die
Compilerähnlichen-Optimierungsverfahren in Tabelle 2 dargestellt. [5]
Optimierung Beschreibung
Common Subexpression Elimination Redundante Anweisungen und Ausdrücke werden eliminiert.
Beispiel: P=A+B+C, Q=A+B+D --> Zusammenfassen von A+B: S=A+B -->
Einsetzen in Ausgangsgleichungen: P=S+C, Q=S+D
Copy Propagation Zuweisungen wie X:=Y werden weit gehend vermieden. Es wird so lange wie
möglich wird mit Y gearbeitet.
Dead-Code Elimination Code der nicht ausgeführt wird, wird entfernt.
Constant Folding Ist eine Variable über den gesamten Programmablauf konstant, so wird sie
durch die entsprechenden Konstante ersetzt.
Loop Invariant Code Removal Code, welcher innerhalb einer Schleife nicht verwendet wird, wird ausserhalb
der Schleife platziert.
Loop Strength Reduction Komplizierte Ausdrücke innerhalb von Schleifen werden vereinfacht.
Beispiel: for (j=x;j>0;j--) {t=4*j; ...} Ersetzen durch: t:=x; for (j=x;j>0;j--)
{t=t-4;...}
Loop Induction-Variable Elimination Elimination von Zählvariablen innerhalb von Schleifen.
Tabelle 2: Compilerähnliche Optimierungen
no
interpret
next
instruction
yes
no fault
found
Rollback
fault
translate region,
store in Tcache
execute
translation
from
Tcache
Beispiel: t=4*j;u=4*i; --> i>j ist identisch mit u>t
chain
Translator
14

Neben den Compilerähnlichen Optimierungen gibt es noch x86 spezifische Optimierungen. Diese beschränken sich auf
das Entfernen unnötig gesetzter Condition Codes. Setzt eine Instruktion bestimmte Flags, welche jedoch von Programm
nicht ausgelesen werden, so ist es nicht notwendig diese Flags zu setzen.
Die letzte Gruppe bilden die VLIW spezifischen Optimierungen. Sie entfernen unnötige Sprünge und können somit
mehrere x86 Codeblöcke vereinen. [1], [3]
Der Ablauf einer Schrittweisen Übersetzung ist in Abbildung 13 dargestellt. [1]
addl
x86 Code
%eax,(%esp) // load data from stack, add to %eax
addl %ebx,(%esp) // ditto, for %ebx
movl %esi,(%ebp) // load %esi from memory
subl %ecx,5 // substract 5 from %ecx register
frontend
ld %r30,[%esp] // load data 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
optimizer
ld %r30,[%esp] // load data 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
scheduler
ld %r30,[%esp]; sub.c %ecx,%ecx,5
ld %esi,[%ebp]; add %eax,%eax,%r30; add %ebx,%ebx,%r30
Abbildung 13: Beispiel einer schrittweisen Übersetzung
15

4. Hardwareunterstützung für Code Morphing Software
4.1 Ausnahmebehandlung
In einem herkömmlichen Prozessor erfolgt die Ausnahmebehandlung durch Hardwaremechanismen. Diese ermöglichen
es, Befehlsketten rückgängig zu machen und somit wieder einen gültigen Zustand im Prozessor herzustellen.
Der Crusoe Prozessor verwendet zur Ausnahmebehandlung zwei Registersätze, welche bereits im Kapitel 2 erwähnt
wurden. Man spricht von der sogenannten „Working Copy“ und von der „Shadow Copy“.
Werden Atome ausgeführt, so wird stets die Working Copy verändert. Wird ein Codeblock vollständig ausgeführt, ohne
dass eine Ausnahme aufgetreten ist, so wird im ersten Molekül des folgenden Codeblocks das Commit Flag auf wahr
gesetzt. Dies bewirkt eine Übertragung aller Werte aus der Working Copy in die Shadow Copy. Es wird also der letzte
gültige Zustand des Prozessors gespeichert.
Die Übertragung zwischen den Registern läuft dabei nahezu ohne Zeitverlust ab.
Tritt während der Ausführung eine Exception auf, so sorgt ein Rollback Befehl für das Wiederherstellen der letzten
gültigen Sicherheitskopie. Es werden also alle Werte der Shadow Copy in die Working Copy übertragen. Anschliessend
werden die Befehle des Codeblocks vom Interpreter In-Order ausgeführt. Dadurch kann die exakte Stelle der Exception
ermittelt werden.
Schwieriger ist es die Änderungen im Speicher zu verfolgen. Dafür ist der Gated Store Buffer zuständig. Sämtliche
Speicher-Operationen werden werden zunächst in ihm ausgeführt. Bei einem Commit werden die Werte in den
Hauptspeicher übertragen. Ein Rollback sorgt für das Leeren des Puffers.
Je nachdem wie häufig ein Fehler auftritt wird der Code entweder vom Interpreter übernommen oder er wird neu
übersetzt. Die Angaben beziehen sich auf [1], [3], [4].
4.2 Alias Hardware
Es ist klar, dass die Freiheit des Schedulers ausschlaggebend für die Performance des Prozessors ist. Je freier er die
Gruppierung der Atome vornehmen kann, umso schneller kann das Programm ausgeführt werden. Dabei ist es wichtig,
dass Speicheroperationen beim Vertauschen berücksichtigt werden. Allgemein ist es günstig load vor store Befehlen
auszuführen, da nachfolgende Operationen nicht auf die Operanden warten müssen. Sollte allerdings ein load ein
vorheriges store benötigen und diese Anweisungen vertauscht wurden sein, so muss dies bei der Ausführung bemerkt
werden. [1]
Hierfür ist die sogenannte Alias Hardware implementiert. Wird ein load Befehl vor einen store Befehl gesetzt, so wird er
durch load-and-protect ersetzt. Dabei wird die Adresse, von welcher geladen wird sowie die Größe des zu ladenden
Datenblocks im Alias-Buffer abgelegt. Der entsprechende store Befehl wird durch store-under-alias-mask ersetzt. Dieser
16

Befehl untersucht zusätzlich, ob er in einen durch load-and-protect geschützten Speicherbereich schreibt.
Sollte ein store Befehl einen solchen Bereich überschreiben, so wird eine Exception aufgerufen und ein Rollback
durchgeführt. [1]
Dadurch ist ein sicheres Vertauschen der Operationen möglich. Abbildung 14 zeigt in einem Beispiel diesen Vorgang.
Abbildung 14: Beispiel Alias Hardware
Es ist möglich den zweiten load Befehl zu eliminieren und mit dem bereits vorher geladenen Wert zu arbeiten. Dabei ist
es jedoch wichtig, dass der store Befehl nicht auf die zu ladende Adresse schreibt. Deshalb werden die Befehle
entsprechend durch load-and-protect und store-under-alias-mask ersetzt. Sollte der store Befehl die zu ladende Adresse
überschreiben, so wird eine Exception aufgerufen. [1]
Abbildung 15 zeigt nun den Ablauf beim Vertauschen von load und store Befehlen.[6]
Alias Buffer stam
yes
Raise
Exception
ldp
ld %r30,[%x] // first load from location X
…
st %data,[%y] // might overwrite location X
ld %r31,[%x] // this accesses location X again
use %r31
ldp %r30,[%x] // load from X and protect it
…
stam %data,[%y] // this store traps if it writes X
use %r30 // can use data from first load
Addr Size
Abbildung 15: Ablauf Alias Hardware
Ein Phänomen, was bei der Verwendung von Aliasing auftreten kann ist das sogenannte falsche Aliasing, welches in
Abbildung 16 in einem kleinen Beispiel dargestellt ist.
Original Übersetzt
…
st %w,[%data1]
ld %data2, [%x]
st %y, [%data3]
ld %data4, [%z]
Abbildung 16: Falsches Aliasing
Aliasing?
Beide load Befehle werden vor einen store Befehl gesetzt und folglich werden sie durch load-and-protect ersetzt, ebenso
werden die store Befehle durch store-under-alias-mask ersetzt. Die Reihenfolge des zweiten und dritten Befehls wurde
dabei nicht verändert. Trotzdem kommt es zu einer Exception, falls X=Y ist. [6]
no
ldp %data2, [%x]
ldp %data4, [%z]
stam %w, [%data1]
stam %y ,[%data3]
X=Y
Continue
Execution
Exception
17

4.3 Selbstmodifizierender Code
4.3.1 Einleitung
Ein weiteres Problem, mit dem dynamische Übersetzer wie die Code Morphing Software umgehen müssen ist
Selbstmodifizierender Code. Er tritt zum Beispiel auf, wenn das Betriebssystem ein neues Programm in den
Hauptspeicher lädt. Aber auch Programme selbst können ihren Code während der Laufzeit ändern.
Wurde dieser Code bereits von der Code Morphing Software übersetzt, so muss diese die Änderungen bemerken. [1],
[3]
Um dies zu realisieren wird der Translation-Bit Buffer genutzt. Für jeden übersetzten Speicherbereich wird ein Bit in
diesem Puffer gesetzt. Sollte nun ein Schreibzugriff auf diesen Speicherbereich durchgeführt werden, so wird der
entsprechende Codeblock neu übersetzt.
Ziel ist es, bei selbstmodifizierendem Code ein häufiges Neuübersetzten zu vermeiden. Dies wäre insbesondere dann
notwendig, wenn Code und Daten vermischt in einem Speicherbereich liegen. Bei jeder Datenänderung würde ebenso
der Code neu übersetzt werden.
Um die Zahl der Neuübersetzungen zu verringern, sind verschiedene Verfahren in der CMS implementiert. Diese
Verfahren sollen in den nächsten Kapiteln vorgestellt werden. Alle Verfahren sind der Quelle [3] entnommen.
4.3.2 Fine Grain Protection
Das erste Verfahren ist die Fine Grain Protection. Dieses relativ einfache Verfahren sorgt dafür, dass mit dem
Translation Bit nicht immer eine komplette Seite im Speicher geschützt werden muss. Lässt sich dieser geschützte
Bereich also verkleinern, dann sinkt die Wahrscheinlichkeit, dass bei einem Code Daten Mix der Codeblock neu
übersetzt wird, wenn sich nur der Datenbereich geändert hat.
Wichtig ist hierbei, dass dieses Verfahren nur für wenige Bereiche gleichzeitig verwendet wird. Damit ist es möglich
den Speicheraufwand für die übersetzten Bereich zu minimieren.
4.3.3 Self Revalidating Translations
Das zweite solche Verfahren sind die Self Revalidating Translations.
Bemerkt die Code Morphing Software den Code Daten Mix, so wird der Übersetzung ein Prolog vorangestellt. Dabei ist
es notwendig, dass die Startadresse des Codeblocks durch die Adresse des Prologs ersetzt wird.
Der konkrete Ablauf soll im Folgenden erläutert werden. Zunächst wird der entsprechende Code, mit einem Flag
18

gekennzeichnet. Wird er danach aufgerufen, so wird der Bereich neu übersetzt. Dabei wird der Code aus den Daten
herausgefiltert. Erkennt nun die Fine Grain Protection einen Schreibzugriff auf den Bereich, so wird der Prolog aktiviert.
Zusätzlich wird der Schutz für den Speicherbereich abgeschaltet. Dadurch verursacht ein erneuter Schreibzugriff auf den
Bereich kein Neuübersetzen des Codes.
Wird der Code später erneut aufgerufen, so gibt der Prolog Auskunft darüber, ob er sich durch die Schreibzugriffe
verändert hat. Sollte dies der Fall sein, so wird er erneut übersetzt.
Ist der Code unverändert, so wird die Protection wieder aktiviert, der Code wird verifiziert, der Prolog deaktiviert und
schließlich wird der Code ausgeführt.
Die Self Revalidating Translations sind sinnvoll, wenn der Code relativ selten verändert wird. Somit kann ein häufiges
Neuübersetzen vermieden werden.
4.3.4 Self Checking Translation
Ein den Self Revalidating Translations ähnliches Verfahren stellen die Self Checking Translations dar.
Hierbei bleibt der Speicherbereich komplett ungeschützt. Dazu ist es notwendig, dass der Code selbst prüft, ob er
verändert wurde. Dabei wird der ursprünglichen Übersetzung Code zum Überprüfen hinzugefügt. Sollte dieser Code
eine Veränderung feststellen, so wird ein Rollback ausgelöst gesendet.
Eine wichtige Bedingung hierbei ist, dass der Code zum Überprüfen nach sämtlichen store Operationen ausgeführt wird.
Denn diese store Befehle könnten den Code verändern. Folglich darf die Alias Hardware diesen Code zum Überprüfen
nicht umsortieren.
Dieses Verfahren bietet vor allem bei selten ausgeführtem Code Einsparungen. Es tritt hierbei ein Overhead von circa
83% auf, jedoch ist die Ausführung dieses Overheads schneller als der Aufruf des Interpreters beziehungsweise die
komplette Neuübersetzung.
4.3.5 Stylized SMC
Die bisher vorgestellten Verfahren sind vor allem dann sinnvoll, wenn nur die Daten innerhalb eines Speicherbereichs
verändert werden. Wenn sich der Code selbst ändert erfordern sie jedoch eine komplette Neuübersetzung.
Anders ist es beim Stylized SMC. Hierbei wird durch eine geschickte Übersetzung vermieden, dass viele Code-
Änderungen auftreten.
Als Beispiel soll der Offset in einer Schleife dienen (Abbildung 17).
label: add %eax, 0x123456
ld
add
%temp, [label+1]
%eax, %eax, %temp
Abbildung 17: Beispiel Stylized SMC
Angenommen die Adresse 0x123456 stellt den Index in einer Schleife dar. Bei jedem Durchlauf würde nun der Code
19

verändert werden. Damit wäre für jeden Schleifendurchlauf ein Aufruf des Interpreters nötig.
Die Übersetzung scheint nun zunächst etwas untypisch. Das vorherige label dient zum Auslesen des Offsets. Die
Adresse [label+1] enthält nun bei jedem Durchlauf den aktuell zu lesenden Speicherbereich. Die Daten werden also
direkt aus dem Code-Stream gelesen.
Dieses Verfahren vermeidet häufige Neuübersetzungen trotz ursprünglicher Veränderung des Codes, es ist jedoch
zusätzlich mit Self Revalidating oder Self Checking zu Überprüfen, ob sich der Code selbst verändert hat.
4.3.6 Translation Groups
Beim letzten Verfahren zur Vermeidung von Neuübersetzung geht man davon aus, dass es lediglich eine geringe Anzahl
verschiedener Versionen des modifizierten Codes gibt. Ist dies der Fall, so ist es sinnvoll die alten Versionen des Codes
für die spätere Verwendung zu speichern.
Die Code-Morphing-Software kann diese Übersetzungen in sogenannten Translation Groups hinterlegen. Dabei steht die
letzte verwendete Version am Anfang der Liste.
Trifft die CMS auf einen Codeblock wird zunächst überprüft, ob die erste Version gültig ist. Schlägt dies fehl, so wird
der Rest der Liste nach der passenden Version durchsucht. Wird ein passender Codeblock gefunden so wird er an den
Anfang der Liste gebracht und ausgeführt. Findet sich in der gesamten Liste ein passender Block, so wird der Code neu
übersetzt und der neue Block an den Anfang der Liste verschoben.
20

5. LongRun Power Management
5.1 Einleitung
Die Bedeutung von Power Management Technologien begann mit der Einführung von leistungsstarken PCs für den
privaten Gebrauch. Es war wichtig geworden Strom zu sparen und somit die Kosten zu senken. Eine besondere
Bedeutung hat das Power Management jedoch im mobilen Sektor. Es ist entscheidend für die Akku-Laufzeit von
Notebooks.
Das Minimieren des Stromverbrauchs hat ebenso eine geringere Abwärme zur Folge. Damit können Kosten für teure
Kühlsysteme gespart werden. Gleichzeitig werden Systeme leiser.
Die verschiedenen Technologien des Power Managements sollen in Tabelle 3 kurz mit ihrer Einführungszeit und
gegebenenfalls dem Hersteller genannt werden.
Jahreszahl Technologie
1990 APM (Advanced Power Management)
1995 ACPI (Advanced Configuration and Power Interface)
2000 SpeedStep (Intel)
2000 LongRun (Transmeta)
2000 PowerNow! (AMD)
2003 Enhanced SpeedStep (Intel)
2003 Enhanced LongRun (Transmeta)
Tabelle 3: Power Management Technologien
Herkömmliche Methoden des Power Managements basieren auf einem stetigen An- und Abschalten des Prozessors.
Dies führt zu einem linearen Verhalten zwischen Leistungsaufnahme und Performance wie in Abbildung 18 zu sehen ist.
[2]
Abbildung 18: Lineares Power Management
21

5.2 LongRun Fähigkeiten
Im Gegensatz zum herkömmlichen Power Management ermöglicht LongRun ein flexibles Verändern von Takt und
Spannung. So lassen sich Frequenzen in 33 MHz Schritten und Spannungen in 25mV Stufen variieren. Insgesamt sind
200 dieser Änderungen je Sekunde möglich.
Die minimale Frequenz beträgt beim TM5400 300MHz, unter dieser Grenze wird das normale ACPI mit An- und
Abschalten des Prozessors verwendet. Dadurch, dass Takt und Spannung nicht im gleichen Verhältnis geändert werden
müssen, wird kein lineares Verhalten zwischen Performance und Leistungsaufnahme erreicht. Damit kann mehr Strom
eingespart werden (Abbildung 19). [2], [4]
Abbildung 20 zeigt die Vorteile von LongRun im Vergleich zum herkömmlichen Power Management. Um den
Prozessor bei herkömmlichen Methoden auf die Hälfte des Taktes zu reduzieren, wird er 50% der Laufzeit in den Sleep
State versetzt. LongRun senkt die Frequenz um weniger als 50% und kann gleichzeitig die Spannung auf mehr als 50%
absenken. [2]
Abbildung 19: LongRun Power Management
Abbildung 20: LongRun im Vergleich
22

5.3 LongRun Funktionsweise
Wie die Absenkung/Erhöhung von Takt und Spannung funktioniert, soll im folgenden Abschnitt erläutert werden.
Ändert sich die Prozessorauslastung, so wird dies von der Code Morphing Software durch das sogenannte
CMS-Monitoring bemerkt.
Ist die Auslastung größer, so gibt LongRun dem Chip vor seine Spannung zu erhöhen. Stabilisiert sich die Spannung auf
den neuen Wert, wird die Frequenz angepasst.
Ist die Auslastung geringer, wird zunächst die Frequenz abgesenkt, synchronisiert sich die Frequenz auf den
vorgegebenen Wert (PLL- phase lock loop) so wird die Spannung abgesenkt. [4]
Die Frequenzänderung muss dabei nicht in einzelnen 33Mhz Schritten erfolgen. Soll beispielsweise der Takt von
600MHz auf 700MHz angehoben werden, so wird zunächst die Spannung in Einzelschritten auf 1.6V gesetzt.
Anschliessend „springt“ die Frequenz auf 700MHz. [4]
Um ein effizientes Power Management zu ermöglichen, ist es notwendig die Reaktionszeiten sehr gering zu halten. Die
Änderung der Prozessorauslastung kann in ½µs festgestellt werden. Spannungsänderungen werden in weniger als 20µs
durchgeführt.
Im Worts Case bedeutet diese lediglich eine Zeitspanne von 280µs bei einer Spannungsänderung von 1.1V auf 1.6V und
einer Frequenzänderung von 200MHz auf 700MHz. [4]
Ein weiterer Vorteil der LongRun Technologie besteht darin, dass bei einer Änderung der Spannung kein Abschalten
des Prozessors notwendig ist. Lediglich das PLL erfordert ein Abschalten von maximal 20µs. [4]
5.4 Weitere LongRun Leistungen
In den letzten Kapiteln wurde die LongRun Technologie mit ihren grundlegenden Fähigkeiten vorgestellt. Neben diesen
gibt es noch weitere Vorteile gegenüber anderen Systemen.
In Kapitel 2 wurde die in den Prozessor integrierte Northbridge genannt. Von ihr profitiert ebenso das LongRun Power
Management. So ist es möglich den Takt und die Spannung des Speichers ebenso wie die des Kerns zu verändern
(Abbildung 21). Dies ermöglicht ein weiteres Herabsenken der Leistungsaufnahme.
Ebenso beinhaltet LongRun eine Technologie namens LongRun Thermal Extension (LTX), welche mit einem
sogenannten „termal budget“ arbeitet. Der Benutzer kann dabei festlegen, wie viel Strom verbraucht werden darf. Im
Performance Mode gibt es beispielsweise keine Einschränkungen für Takt und Spannung. Im Economy Mode wird ein
maximaler Stromverbrauch festgelegt. Somit kann der Nutzer selbst entscheiden, ob er seine Priorität auf volle
Performance oder auf lange Akku Laufzeiten legt.
Damit entsprechenden Änderungen der Lüfterdrehzahl und der Takt und Spannungsänderungen effizient arbeiten,
werden die Clock Throttling Register aus der Southbridge vom BIOS in die Northbridge repliziert. Damit kommt es bei
der Übertragung zu keinem Overhead. [2], [4]
23

Abbildung 21: Integrierte Northbridge
24

6. Zusammenfassung
In der vorliegenden Ausarbeitung wurde ein Überblick über den Crusoe Prozessor der Firma Transmeta gegeben. Im
Vordergrund dabei stand die Code Morphing Software, welche das Herzstück des Prozessors ist. Es wurde erläutert wie
diese Software das Ausführen von x86 Anwendungen auf dem VLIW-Kern ermöglicht.
Um das Reibungslose Übersetzen zu ermöglichen benötigt der Crusoe verschiedene Hardwareimplementationen, welche
vor allem die Ausnahmebehandlung unterstützen. Neben der Code Morphing Software wurde auch das LongRun Power
Management vorgestellt. Dieses erlaubt es, dass Notebooks ihre Akku Laufzeit erheblich vergrößern.
Der Crusoe bietet ein neuartiges und innovatives Konzept. Die Möglichkeit neben x86 Befehlen auch andere
Instruktionen zu übersetzen bietet ein breites Einsatzspektrum. Leider wurde diese Möglichkeit bisher nicht
ausgeschöpft.
Der übersetzte Code wird umso schneller, je länger Anwendungen ausgeführt werden. Ist er vollständig optimiert, so
steigt die Ausführungsgeschwindigkeit stark an. Darin ist ein besonderer Vorteil des Crusoe zu sehen, da solch
vielseitige Optimierungen bei herkömmlichen Prozessoren fehlen.
Ebenso Vorteilhaft ist, dass die CMS per Flash Update aktualisiert werden kann. Damit können Fehler innerhalb der
Architektur ausgeglichen werden und es ist eine Implementierung neuer Befehle möglich. Eine solche Funktion ist in
anderen Prozessoren ebenfalls kaum vorhanden.
Ausserdem ist der Crusoe Prozessor aufgrund des geringen Hardware Teils kostengünstig zu erwerben und durch den
geringen Energieverbrauch können weitere Einsparungen erzielt werden.
Neben diesen positiven Eigenschaften gibt es in der Crusoe-Architektur auch durchaus Nachteile. So ist die Performance
besonders beim Häufigen Wechsel von Aufgaben sehr gering, da die CMS diese Softwareteile nicht optimiert.
Weiterhin ist der zusätzliche Speicherbedarf zu nennen. In heutigen Systemen fallen die 16MB, welche als Translation
Cache verwendet werden kaum ins Gewicht. Betrachtet man jedoch Webpads oder einfache Subnotebooks, so können
sich diese Speichereinbußen negativ auf die Performance auswirken.
Ein weiteres Problem stellt die Ausnahmebehandlung dar. Sie ist perfekt auf die Architektur zugeschnitten, muss jedoch
aufgrund der dynamischen Übersetzung relativ komplex implementiert werden. Besonders bei der Verwendung von
Selbstmodifizierendem Code sind dabei Performanceverluste in Kauf zu nehmen.
Abschliessend ist zu sagen, das Crusoe ein im Gesamteindruck positives Konzept liefert. Es ist jedoch bisher nicht
gelungen auf dem Markt Fuss zu fassen. Die Entwicklung des Efficeon Prozessors wird ausschlaggebend für die Zukunft
von Transmeta sein.
25

Literaturverzeichnis
[1] Alexander Klaiber: The Technology Behind Crusoe Processors. White paper, Transmeta Corporation, Januar
2000
[2] Marc Fleischmann: LongRun Power Management – Dynamic Power Management for Crusoe Processors.
White paper, Transmeta Corporation, 17.01.2001
[3] James C. Dehnert, u.w.: The Transmeta Code Morphing Software – Using Speculation, Recovery, and
Adaptive Retranslation to Adress Real-Life Challenges. White paper, Transmeta Corporation
[4] Tom R. Halfhill: Transmeta breaks x86 Low-Power Barrier – VLIW Chips use Hardware-Assisted x86
Emulation. Microprocessor Report, 14.2.2001
[5] A. Artale: Principle of Compilers: Lecture IX: Principles of Code Optimization. Vorlesungsunterlagen, Free
University of Bolzano, 2004
[6] Erik R. Altman: Dynamic Binary Translation and Optimization: DAISY, Crusoe, Dynamo. Micro-33 Tutorial,
13.12.2000
[7] Andreas Stiller: Zu Neuen Ufern – Transmeta enthüllt Crusoe Design. Zeitschriftenartikel in c't 2000/03 S. 32,
Heise Verlag
[8] Nico Ernst: Transmeta-Crusoe im Detail. http://www.tecchannel.de/hardware/256/index.html, 24.01.2000
Stand 12.12.2004.
[9] Dieter Kranzlmüller: Transmeta's Crusoe. Vorlesungsunterlagen Technische Informatik und Telematik. UNI
Linz
[10] Transmeta Corp., http://www.ecoreporter.de, Stand 12.11.2004
[11] http://www.transmeta.com
Abbildungsquellen
Abbildung 1 : [8]
Abbildungen 2,3 : [11]
Abbildungen 4,5 : [1]
Abbildungen 6,7,9,10 : [4]
Abbildung 11 : [9]
Abbildungen 18,19,20,21 : [2]
26