26
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

Der Transmeta Crusoe Prozessor - TU Bergakademie Freiberg · 1.2 Der Crusoe Prozessor Die Entwicklung des Crusoe Prozessors begann zeitgleich mit der Firmengründung. Über die gesamte

Embed Size (px)

Citation preview

Der Transmeta CrusoeProzessor

Ausarbeitung zum Vortrag im Seminar: Projekte der Informatik WS 04/05an der TU-Bergakademie Freiberg

Dirk BräuerJanuar 2005

1

Inhaltsverzeichnis1. Einleitung......................................................................................................................................... 6

1.1 Die Firma Transmeta................................................................................................................. 61.2 Der Crusoe Prozessor.................................................................................................................7

2. Der Aufbau des Crusoe Prozessors.................................................................................................. 83. Die Code-Morphing-Software (CMS)............................................................................................11

3.1 Einleitung.................................................................................................................................113.2 Befehlsverarbeitung................................................................................................................. 113.3 Struktur.................................................................................................................................... 13

4. Hardwareunterstütrzung für Code Morphing Software..................................................................164.1 Ausnahmebehandlung..............................................................................................................164.2 Alias Hardware........................................................................................................................ 164.3 Selbstmodifizierender Code.....................................................................................................18

4.3.1 Einleitung......................................................................................................................... 184.3.2 Fine Grain Protection....................................................................................................... 184.3.3 Self Revalidating Translations......................................................................................... 184.3.4 Self Checking Translation................................................................................................194.3.5 Stylized SMC................................................................................................................... 194.3.6 Translation Groups...........................................................................................................20

5. LongRun Power Management........................................................................................................ 215.1 Einleitung.................................................................................................................................215.2 LongRun Fähigkeiten...............................................................................................................225.3 LongRun Funktionsweise........................................................................................................ 235.4 Weitere LongRun Leistungen.................................................................................................. 23

6. Zusammenfassung.......................................................................................................................... 25

2

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

3

TabellenverzeichnisTabelle 1: Crusoe Prozessoren............................................................................................................. 7Tabelle 2: Compilerähnliche Optimierungen..................................................................................... 14Tabelle 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.

6

Abbildung 1: Firmensitz

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

7

Abbildung 2: TM3120 & TM5400

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.

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]

8

Abbildung 3: Schichtenaufbau des Crusoe

Abbildung 4: Temperatur TM5400 Abbildung 5: Temperatur Pentium II

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.

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

Abbildung 6: Hardwaredesign TM5400

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]

10

Abbildung 7: Hardwaredesign TM3120

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]

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

Abbildung 8: CMS - Startup

512kByteFlashROM

CMS

2 MBytes ofCrusoe Code

14 MByte ofCrusoe data

8 KB CrusoeLocal Ins Mem

8 KB CrusoeLocal Data Mem

Decompress

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]

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

Abbildung 9: Molekülkombinationen

Abbildung 10: Pipelinestruktur

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

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

Abbildung 11: Befehlsverteilung verschiedener Architekturenx86 CrusoeVLIW

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]

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

Beispiel: t=4*j;u=4*i; --> i>j ist identisch mit u>t

Tabelle 2: Compilerähnliche Optimierungen

14

Abbildung 12: Flussdiagramm der CMS

exceededtranslation

Threadhold?

find nextinstructionin Tcache?

Start

Rollbackinterpret

nextinstruction

translate region,store in Tcache

executetranslation

fromTcache

yes

chain

no

Inte

rpre

ter Tran

slator

fault

no fault

found

notfound

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]

15

Abbildung 13: Beispiel einer schrittweisen Übersetzung

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

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

addl %eax,(%esp) // load data from stack, add to %eax addl %ebx,(%esp) // ditto, for %ebxmovl %esi,(%ebp) // load %esi from memorysubl %ecx,5 // substract 5 from %ecx register

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

frontend

optimizer

scheduler

x86 Code

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.

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]

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.

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]

17

Abbildung 14: Beispiel Alias Hardware

Abbildung 15: Ablauf Alias Hardware

Addr Size

Alias Buffer

Aliasing?

ldp

stam

ContinueExecution

RaiseException

no

yes

Abbildung 16: Falsches Aliasing

st %w,[%data1] ld %data2, [%x]st %y, [%data3]ld %data4, [%z]

ldp %data2, [%x] ldp %data4, [%z]stam %w, [%data1]stam %y ,[%data3]

X=YException

Original Übersetzt

ld %r30,[%x] // first load from location X…st %data,[%y] // might overwrite location Xld %r31,[%x] // this accesses location X againuse %r31

ldp %r30,[%x] // load from X and protect it…stam %data,[%y] // this store traps if it writes Xuse %r30 // can use data from first load

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

Angenommen die Adresse 0x123456 stellt den Index in einer Schleife dar. Bei jedem Durchlauf würde nun der Code

19

Abbildung 17: Beispiel Stylized SMC

label: add %eax, 0x123456 ld %temp, [label+1]add %eax, %eax, %temp

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 Technologie1990 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]

21

Abbildung 18: Lineares Power Management

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]

22

Abbildung 19: LongRun Power Management

Abbildung 20: LongRun im Vergleich

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

24

Abbildung 21: Integrierte Northbridge

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