18 Milliarden Gigabyte ...

Inhaltsverzeichnis

Nach sieben Jahren Entwicklungszeit ist es jetzt soweit: Mit dem 64-bittigen Itanium drängt Intel - recht spät übrigens - auf einen schon gut besetzten Markt. CPUs wie Suns UltraSPARC, Compaqs Alpha, Hewlett-Packards PA-RISC oder der MIPS-Prozessor glänzen seit Jahren mit 64 Bit Datenbreite und stecken heutzutage sogar schon in Handhelds und Spielkonsolen. Auch Intel hat sich bereits 1989 mit dem i860 an einem 64-Bitter versucht. Vollwertige 64-Bit-Systeme blieben bislang dennoch eine recht kostspielige Angelegenheit und weitgehend auf große Server und leistungsstarke Unix-Workstations beschränkt.

Aber der Itanium als erster Vertreter der IA-64-Architektur bringt nicht nur den Sprung auf 64 Bit. Anders als der Sledgehammer des Erzkonkurrenten AMD, der die bewährte x86-Architektur behutsam auf 64 Bit erweitern soll, bricht der neue Intel-Spross radikal mit der x86-Tradition. Features wie EPIC (Explicitly Parallel Instruction Computing), reichlich Register und spekulative Programmausführung sollen einen ordentlichen Leistungsschub bringen - und stellen Programmierer und Compiler-Bauer vor ganz neue Herausforderungen. Die Details der IA-64-Architektur finden Sie unter der Überschrift ‘Architektur für echte Programmierer’ im Anschluss an diesen Artikel; ab Seite 154 präsentieren wir erste Benchmarkergebnisse mit dem neuen Prozessor.

Viele fragen sich, was die 64 Bit eigentlich in der Praxis bringen - schließlich beginnen die großen PC-Hersteller in den nächsten Wochen mit der Auslieferung erster Systeme. Intel spekuliert dabei auf ein ähnliches Massengeschäft wie schon zuvor bei den Prozessoren der 16- und 32-Bit-Generation: Vergleichsweise günstige Preise sollen die Nachfrage ankurbeln und so den Verkauf in Gang bringen, was letztlich zu einer kostengünstigen Massenproduktion - und damit zu sinkenden Preisen - führt. Gehören die x86-Prozessoren also demnächst zum alten Eisen, so wie der 32-bittige 386er damals binnen kurzem dem 80286 den Garaus gemacht hat?

Nun, ganz so schnell wird es wohl nicht gehen. Intels Roadmap schreibt die 32-bittige Pentium-Linie noch für mindestens fünf Jahre fort. Der Prozessor-Hersteller will mit dem Itanium erst mal das traditionelle 64-Bit-Segment aufmischen und die Server und High-End-Workstations erobern. Den klassischen PC auf oder unter dem Schreibtisch treibt nach Intels Vorstellungen noch auf absehbare Zeit eine traditionelle IA-32-CPU - am besten natürlich ein hochgetakteter Pentium-4. Und doch: Das Ende der 32-Bit-Ära rückt in greifbare Nähe.

Die vielleicht nahe liegende Erwartung, dass ein 64-Bit-System doppelt so schnell zu Werke geht wie ein 32-Bit-System, ist allerdings ein glatter Irrtum. Letztlich sagt die Datenbreite nur etwas darüber aus, wie viele Bits ein Prozessor in einem Arbeitsschritt verarbeiten kann und wie breit seine Register angelegt sind. Viele Daten benötigen jedoch gar keine 64-bittige Verarbeitung: Grafiken etwa kommen auch bei True Color mit einer Farbtiefe von 32 Bit aus, und Texte bestehen nach wie vor aus Zeichen mit acht oder - bei Unicode - 16 Bits. Zudem können schon die heute in PCs gebräuchlichen 32-bittigen x86-Prozessoren dank geeigneter Multimedia-Erweiterungen wie SIMD in MMX 64-Bit-Werte in einem Schritt verarbeiten und über PCI64 64-bittig mit schneller Hardware wie Gigabit-Ethernetkarten kommunizieren.

Der wahre Vorteil einer 64-Bit-Architektur liegt ganz woanders: Sie birgt nicht nur ein Rechenwerk mit 64 Bit breiten Registern, sondern stellt für die Software auch einen Adressraum zur Verfügung, der bis zu 2⁶⁴ Adressen - also 18 Milliarden GByte - umfasst. Derartige Speichermengen wird man in nächster Zeit wohl noch nicht brauchen; aber in den mit 32 Bit maximal adressierbaren 4 GByte wird es einigen Anwendungen schon heute zu eng.

Speicher satt

So lange ist es noch nicht her, da ließ sich Bill Gates zu der Aussage hinreißen, die 640 KByte Adressraum von MS-DOS seien für immer und ewig genug - und nun soll das Sechstausendfache an RAM schon knapp werden? Wenn man sich vergegenwärtigt, dass die Speicherausstattung eines Standard-PC demnächst 256 MByte RAM erreicht und dass 45 Minuten digitales Video im DV-Format knapp 9,5 GByte belegen, kommen einem die 4 GByte Adressraum aktueller PC-Architekturen schon gar nicht mehr so gewaltig vor. Sicher, im Moment verlangen nur wenige Serveranwendungen nach noch mehr Speicher - etwa umfangreiche Datenbanken, die fürs Caching von Indizes und Tabellendaten gar nicht genug Speicher haben können. Doch die Zeichen der Zeit sprechen eine eindeutige Sprache: In wenigen Jahren wird es eng in den 4 GByte der aktuellen 32-Bit-Architekturen - nicht nur für Server und fette High-End-Workstations.

Erst auf den zweiten Blick zu erkennen: Der Itanium bringt Adressraum bis zum Abwinken und Hauptspeicher satt.

Intels Versuche, der alten IA-32-Architektur auf die Schnelle größere Adressräume beizubringen, sind denn auch im Halbgaren stecken geblieben, dokumentieren allerdings auch den dringenden Wunsch nach mehr Speicher. Mit dem PentiumPro kam die 36-bittige Page Size Extension (PSE36) mit 64 GByte adressierbarem Speicher, auf den sich jedoch auch nur sehr mühselig zugreifen ließ. Der Pentium II brachte dann mit PAE (Physical Address Extension) eine etwas leichter handhabbare Methode, einen Adressraum von ebenfalls bis zu 64 GByte zu nutzen.

Aus Softwaresicht handelt es sich dabei freilich immer noch um eine Krücke: Da die Register zum Adressieren einzelner Zellen nach wie vor nur 32 Bit breit sind, muss der Speicher über 4 GByte in diesen Adressraum eingeblendet werden. (Bei alten x86-Hasen mag da eine vage Erinnerung an die Expanded Memory Specification - EMS - wach werden.) Dazu braucht man spezielle Funktionen des Betriebssystems, was die Software auf eine Plattform festlegt. Außerdem kostet das Einblenden Zeit, was sich je nach Lokalität der Daten in deutlich höheren Laufzeiten als in einem linear adressierbaren Raum niederschlägt. Unsere Erfahrungen unter Windows 2000 finden Sie auf Seite 147.

Nebenwirkungen

Benötigen Anwendungen mehr als 4 GByte Hauptspeicher, geht daher kein Weg an ‘echten’ 64 Bit vorbei - sieht man von Zwischenlösungen ab, wie sie in der Mainframe-Welt immer mal wieder versucht wurden. Zahlreichen Anwendungen kann die damit verbundene höhere Datenbreite freilich auch Nachteile bescheren. 64-Bit-Prozessoren bevorzugen Daten und Befehlsfolgen, die auf glatten 8-Byte-Adressen liegen. Jeden Speicherzugriff auf eine nicht durch 8 teilbare Adresse bestraft der Itanium mit einer Verzögerung - die fällt bei einigen Befehlen sogar massiv aus, weil das Betriebssystem ein solches ‘anstößiges’ Kommando in Software ausführen muss.

Code erwartet der neue Intel-Spross in 128-Bit-Bundles mit jeweils drei Befehlen, die auf glatten 16-Byte-Adressen ausgerichtet sein müssen. Der Compiler muss die Befehle beim Übersetzen einer IA-64-Anwendung entsprechend im Speicher organisieren. Allerdings lassen sich nicht beliebige Instruktionen zu einem solchen Befehlsbundle zusammenfassen: Im Extremfall muss der Compiler einen Befehl mit zwei NOP-Instruktionen in einem Bundle gruppieren. Der Preis: Programme werden speichergieriger, die Codedichte ist schlechter als bei anderen RISC-Systemen. Auch leistungssteigernde Neuerungen der IA-64-Architektur wie EPIC und spekulative Programmausführung blähen den Speicherbedarf von Itanium-Programmen auf - einzelne Testprogramme wuchsen bei uns auf das dreifache Volumen, verglichen mit x86-Code.

Der Speicherausbau des ‘Durchschnitts-PC’ verdoppelt sich jedes Jahr.

Aber natürlich braucht man überhaupt erst mal 64-Bit-Anwendungen, damit der Itanium seine Power ausspielen kann. Zwar führt der Prozessor auch 32-Bit-Programme aus, geht dabei jedoch deutlich langsamer zur Sache als ein gleich schnell getakteter IA-32-Prozessor. Für den Lieblings-Editor oder ein paar Systemverwaltungstools mag das noch reichen; aber wenn es um Leistung geht, muss ein speziell für den Itanium kompiliertes Programm her. Von dem entscheidenden Vorteil des Itanium - dem größeren Adressraum - können überhaupt nur 64-Bit-Programme profitieren.

Wer nun freilich denkt, dass die Entwickler mal eben den Quellcode durch einen neuen Compiler jagen müssen, um ihre Programme 64-bittig zu machen, stellt sich das zu einfach vor. Nur die wenigsten x86-Anwendungen sind so programmiert, dass sie sich ganz ohne Probleme für ein 64-Bit-System kompilieren lassen. So mancher Entwickler, der nur auf x86-Systemen werkelt, verlässt sich blind darauf, dass ein Pointer in einen int passt - was bei den 64-bittigen Pointern und 32-bittigen int-Variablen auf 64-Bit-Systemen schief geht. Je näher ein Programmierer am Prozessor arbeitet, die APIs des Betriebssystems umgeht und auf der Ebene einzelner Bits und Bytes herumpfriemelt, desto eher muss er bei der Portierung auf 64 Bit mit Schwierigkeiten rechnen.

Problematisch ist auch wieder mal die Portabilität von 64-Bit-Code zwischen den verschiedenen Betriebssystemen. Während sich das Unix-Lager auf ein Modell der Open Group geeinigt hat, das die Größe der wesentlichen Datentypen festlegt [1], geht Microsoft hier andere Wege. Wer sowohl für Unix als auch für Windows 64-bittig programmieren will, muss sich beispielsweise mit long-Variablen herumschlagen, die hier 64 Bit und dort nur 32 Bit groß sind. Microsoft vereinfacht damit das Portieren von Projekten von 32 auf 64 Bit, da der viel verwendete Typ long keine Änderungen erfordert und sich so Binärdateien weiter lesen lassen.

Fenster, ganz breit

Microsoft kann zur Markteinführung des Itanium nur Vorabversionen von Windows XP vorweisen, die sich noch unter dem alten Codenamen Whistler melden. Die 64-Bit-Version von Windows XP Professional für den Workstation-Einsatz soll zum 25. Oktober zusammen mit den 32-Bit-Ausgaben erscheinen, der Server (Windows 2002) kommt wie seine 32-Bit-Brüder erst im Jahr 2002. Die Vorabversionen, die uns derzeit zur Verfügung stehen, entsprechen der zweiten Beta von Windows XP (Build 2462).

64 Bit sind für Microsoft nichts Neues: Der XP-Vorgänger Windows NT lief in den ersten Versionen auf Intels i860-Prozessor, später auch auf dem ebenfalls 64-bittigen MIPS R4000. Letztlich entschied sich Microsoft aber dafür, das System auf 32-Bit-Adressen auszulegen. Erst eine Laborversion von NT für den Alpha überwand diese Einschränkung; sie ist aber inzwischen wieder gänzlich von der Bildfläche verschwunden.

Auf dem Itanium führt Windows ausschließlich 32- und 64-Bit-Code aus. Die in den 32-Bit-Versionen integrierte DOS-Emulation fehlt ebenso wie die Fähigkeit, alte 16-Bit-Windows-Programme abzuarbeiten. Das ist, mag man einwenden, doch gar nicht so schlimm - wer will sich im anbrechenden 64-Bit-Zeitalter noch mit den Relikten der längst vergangenen 16-Bit-Welt herumschlagen? Allerdings beginnen viele Installationsprogramme ihre Arbeit als 16-Bit-EXE-Datei. Microsoft hat deshalb für die beiden am meisten eingesetzten Installationsmechanismen (das Microsoft-eigene ACME und InstallShield 5.x) eine Emulationsschicht geschaffen, damit sich derartige Anwendungen auch auf einem 64-Bit-System installieren lassen.

Das Ausführen von 32-Bit-Programmen übernimmt eine spezielle Emulationsschicht namens WOW64 (für Windows On Windows 64 Bit), was einige Einschränkungen bei der Zusammenarbeit von 32- und 64-Bit-Prozessen mit sich bringt. So können sie keine DLLs gemeinsam nutzen, da sich hier 32- und 64-Bit-Code nicht mischen lässt. Davon sind auch DCOM-Komponenten betroffen: Inproc-Server wie DirectX müssen in einer 64-Bit-Version vorliegen, damit sie in einem 64-Bit-Programm verwendbar sind.

Angesichts eines neuen Befehlssatzes müssen alte x86-Hasen umlernen.

Das Gleiche gilt für Treiber: 32-Bit-Treiber funktionieren in einem 64-Bit-Betriebssystem nicht. Und auch etliche systemnahe Programme wie Antivirensoftware mit eigenen Dateisystemtreibern wird man sich wohl neu beschaffen müssen. In seinen Release Notes zur Beta 2 weist Microsoft ferner daraufhin, dass auch 32-bittige Server-Anwendungen nicht auf dem 64-Bit-Windows laufen. Wo genau die Einschränkung hier liegt, war bis Redaktionsschluss nicht in Erfahrung zu bringen - man kann aber vermuten, dass es sich um eine Einschränkung innerhalb des Dienstkonzepts der 64-Bit-Versionen von Windows XP/2002 handelt.

Wer mit einem Itanium-System für Windows XP/2002 liebäugelt, muss also auch einen Gutteil seiner Software-Grundausstattung erneuern - für systemnahe und speicherhungrige Software ein Muss, für performancegierige Programme dringend zu empfehlen. Noch vor der offiziellen Markteinführung von XP im Oktober und vor der Markteinführung der Windows-2002-Serverfamilie im nächsten Jahr will Microsoft weitere Vorabversionen der Betriebssysteme für Itanium-Käufer bereitstellen - sie sollen die Software vom jeweiligen Hardware-Verkäufer beziehen können.

Für Entwickler, die schon heute ihre Software an die kommende 64-Bit-Generation anpassen wollen, stellt Microsoft ein spezielles Win64-SDK zur Verfügung [8]. Diese Vorabversion enthält entgegen sonstigen Gepflogenheiten auch Compiler und Linker, also alles, was man zum Erzeugen von Software grundsätzlich braucht. Hier finden sich auch zahlreiche Hinweise für das Portieren von 32-Bit-Software; Werkzeug, das diese Aufgabe zumindest in Teilen automatisch angeht, gibt es diesmal - anders als seinerzeit beim Umstieg von 16- auf 32-Bit-Windows - jedoch nicht. Allerdings bringt das 64-Bit-Windows nur ein geringfügig überarbeitetes API mit, sodass die Umstellung einer Anwendung von Win32 auf Win64 deutlich weniger aufwendig ausfallen dürfte als die von Win16 auf Win32.

Auch Intel hat einen Compiler im Angebot, der Itanium-Code erzeugen kann [2] - wenn auch bislang nur in einer Vorabversion. Daneben findet man bei Intel reichlich Informationen zu Windows 64 und dessen Programmierung [4]. Wie von dem IA-64-Entwickler nicht anders zu erwarten, steht bei dem hauseigenen Compiler das Generieren von optimalem Itanium-Code im Vordergrund. Hier bürdet der neue Prozessor den Compilerbauern nämlich einiges an Arbeit auf: Ein auf die Besonderheiten der IA-64-Architektur optimierter Code kann die Geschwindigkeit eines Programmes leicht um den Faktor fünf und mehr beschleunigen.

Bin schon da

Neben Windows steht mit Linux ein weiteres 64-Bit-Betriebssystem bereit, das ursprünglich aus der x86-Welt kommt. Auch das einstmalige ‘PC-Unix’ betritt mit dem Itanium keineswegs Neuland, läuft es doch schon seit Jahren auf anderen 64-Bit-Prozessoren. Sowohl der Kernel als auch die meisten Anwendungen sind längst 64-Bit-fest.

Diesen Vorteil hat auch Intel erkannt und frühzeitig in die Entwicklung von Linux/ia64 investiert. Das IA-64-Linux-Projekt [3], vor zwei Jahren von den Itanium-Entwicklern Intel und HP zusammen mit diversen Linux-Spezialisten als Trillian-Projekt gegründet, koordiniert die Arbeiten. Bereits im Februar vergangenen Jahres veröffentlichte es einen Itanium-Port des Linux-Kernels, der schnell in den Entwicklerkernel 2.3.50 integriert wurde. Seit Linux 2.4 gehört der IA-64-Zweig ganz offiziell zum Anwenderkernel.

Ein neuer Prozessor bringt auch neue Kernel-Optionen.

Entsprechend besteht auch kein Mangel an Linux-Distributionen für den Itanium: Von Caldera bis TurboLinux stehen die Distributoren Gewehr bei Fuß - SuSE und Red Hat bieten sogar schon ihre aktuellen Distributionen mit dem Kernel 2.4.4 und 2.4.3 in IA-64-Versionen an. All diese Distributionen kommen mit den üblichen Programmen daher, die man von den etablierten x86-Distributionen kennt - an Anwendungen jeglicher Couleur besteht also kein Mangel. Schon auf der letztjährigen CeBIT präsentierte HP eine Itanium-Workstation unter Linux mit XFree86 und dem Gnome-Desktop.

Wer Linux von anderen Plattformen her kennt, wird sich auf einem Itanium-Rechner mit Linux gleich zuhause fühlen. IA-64-Spezifisches muss man geradezu suchen: im /proc-Verzeichnis zum Beispiel, wo die Dateien unterhalb /proc/pal/cpun detaillierte Auskunft über die eingebauten Prozessoren geben. Auch beim Kompilieren eines neuen Kernels wird man im ‘General Setup’ einiges Ungewohnte entdecken.

Linux-Anwendungen, die man im Quellcode erhält, sollten eigentlich schon 64-Bit-fest programmiert sein und sich auf einem Itanium-System problemlos übersetzen lassen. Die Betonung liegt auf ‘sollten’ - sicherheitshalber empfiehlt es sich, mit der Option ‘-Wall’ zu kompilieren und der Ursache von Warnungen à la ‘cast from pointer to integer of different size’ auf den Grund zu gehen.

Vorkompilierte Binaries oder fertige rpm-Archive für Intels 64-Bitter freilich sind außerhalb der speziell für den Itanium erstellten Distributionen noch kaum zu finden. Bei den Serveranwendungen dürfte sich das mit der Verfügbarkeit von Itanium-Rechnern schnell ändern; SAP beispielsweise führte sein R/3 auf Linux/ia64 schon auf dem LinuxTag vor einem Jahr vor. Bis man freilich jedes Linux-Programm als IA-64-Binary erhält, wird es wohl noch etwas dauern.

Schmalspur

Wie Windows kann auch Linux auf dem Itanium 32-bittige x86-Anwendungen ausführen - und keine 32-bittigen Treiber verwenden. Aber zum Glück stecken bei Linux ja fast alle Treiber in den Kernelquellen oder sind zumindest als Quellcode erhältlich. Und auch unter Linux ist die Performance von 32-Bit-Anwendungen alles andere als berauschend. Eine einfache Matrix-Multiplikation - wenn auch sicher kein ganz repräsentativer Benchmark - benötigte als 32-Bit-Binary auf einem Itanium-667 deutlich länger als auf einem Celeron-300. Leistungshungrige Anwendungen muss man daher als 64-Bit-Binaries speziell für den Itanium kompilieren.

Dabei spielt allerdings die Wahl des richtigen Compilers eine entscheidende Rolle. Der GNU C Compiler gcc erzeugt zwar IA-64-Programme, drückt sich in der aktuellen Version 2.96 aber vor der wichtigen Aufgabe der Code-Optimierung. Mit SGIs Pro64-Compiler [5] übersetzt, lief unsere Matrix-Multiplikation um ein Mehrfaches schneller als mit dem gcc; und auch der schon erwähnte Intel-Compiler ist bereits in einer Linux-Version verfügbar.

Aber selbst der gcc, Standard-Compiler unter Linux, legt zu: Die Version 3.0, an der die gcc-Entwickler zurzeit werkeln, schlägt sich auf dem Itanium bereits erkennbar besser als der gcc 2.96. Auf dem ‘GCC for IA-64 Summit’ Anfang Juni haben Vertreter von HP, IBM, Intel und Red Hat mit den freien Entwicklern über die Marschrichtung für die Zukunft diskutiert. Wenn erst mal eine größere Zahl von gcc-Programmierern über eigene Itanium-Maschinen verfügt, wird es mit dem GNU Compiler wohl zügiger vorangehen.

Selbst Entwickler, die ihre Linux-Anwendungen auf dem IA-64 testen möchten, ohne das nötige Kleingeld für eine Itanium-Workstation zu haben, stehen nicht im Regen. Compaq gewährt den Zugang zu einem Itanium-Testsystem unter Linux, auf dem man eigene Programme übersetzen und testen kann [6]. Eine Alternative ist HPs Software-Emulator, der unter Linux/x86 einen Itanium-Prozessor samt vollständiger Linux-Umgebung simuliert [7].

Sag niemals nie

Wer nun denkt, dass er sich beim Itanium-Einsatz zwischen Windows und Linux entscheiden müsse, der irrt: Auch anderswo wird bereits an Betriebssystemen für den neuen Intel-Prozessor gestrickt. IBM hat eine Version von AIX fertig, HP sein HP-UX. Diese Unix-Varianten sind vor allem für Kunden gedacht, die ihre in die Jahre gekommenen AIX- oder HP-UX-Server durch Intels neuen 64-Bitter ablösen wollen, ohne dabei auch gleich die Software ändern zu müssen. HP hat an der Architektur des Itanium kräftig mitgestrickt; so ist es kein Wunder, dass HP-UX auf dem Itanium auch Binärdateien ausführen kann, die ursprünglich für HPs PA-RISC-Prozessoren übersetzt wurden. Das allein zeigt schon, dass HP weniger die PC-Welt erobern will, als sich vielmehr für den Fall rüstet, dass die Luft für etablierte 64-Bit-Architekturen wie PA-RISC durch den Itanium dünner wird.

Von Novell, die einst auch Netware für den Itanium liefern wollten, ist nicht mehr viel zu hören. Mittlerweile heißt es nur noch, dass man nach und nach Teile einer zukünftigen Netware-Version auch für den Itanium anbieten wolle. Bei anderen Betriebssystemschmieden muss man ebenso abwarten, was die Zukunft bringt. Sun etwa hat schon lange eine 64-bittige Solaris-Version für den UltraSPARC. Das Unternehmen hatte erst eine Solaris-Version für den Itanium versprochen, sich dann aber mit Intel überworfen und das IA-64-Solaris wieder abgekündigt. SCO ist seit dem Kauf durch Caldera sowohl bei Linux als auch im Unix-Lager aktiv. Das einstmals in Zusammenarbeit mit IBM geplante Monterey ist jetzt allerdings in AIX 5 aufgegangen.

Wie schon das Gates-Zitat von den ‘für immer ausreichenden 640 KByte Speicher’ zeigt: Prognosen für die Ewigkeit haben im Computergeschäft eine kurze Lebensdauer. Die demnächst ausgelieferten Itanium-Systeme werden sicherlich erst mal in die Serverräume wandern und sich auf einige spezielle, besonders speicherintensive Anwendungen beschränken. Nicht zuletzt stehen die fünfstelligen Dollar-Preise der ersten Systeme noch dem Einsatz auf dem heimischen Schreibtisch entgegen.

Doch wenn es mit dem Preisverfall und Leistungsgewinn bei PCs so weiter geht wie in den vergangengen zehn Jahren, dann wird es wohl keine zwei Jahre dauern, bis die PC-Schmieden Itanium-Rechner für den Desktop in Stückzahlen absetzen. Etwaige Nachschubprobleme mit geeigneter Software sollten sich bis dahin erledigt haben. (ps)

Literatur

[1] LP64-Modell der Open Group

[2] Intel-Compiler

[3] IA-64-Linux-Projekt

[4] 64-Bit-Windows

[5] SGI Pro64 Compiler

[6] Compaq Testdrive

[7] HPs IA-64-Simulator

[8] Win64-SDK (odi)