64-Bit-Architektur

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von 64-Bit)
Zur Navigation springen Zur Suche springen

Als 64-Bit-Architektur werden Prozessorarchitekturen bezeichnet, die 64-bittige Adressregister unterstützen. Sie sind damit in der Lage, einzelnen Prozessen größere (nicht segmentierte) Adressräume als 4 GByte zur Verfügung zu stellen.

Einige Prozessoren unterstützen (aus Kompatibilitätsgründen) mehrere Architekturen, so unterstützen aktuelle PC-Prozessoren von AMD und Intel die x86-16-Architektur des Intel 8086, die x86-32-Architektur des Intel 80386 und die x86-64-Architektur von AMD64/Intel 64.

Analog dazu werden auch Betriebssysteme und Computerprogramme, die auf eine solche Architektur ausgelegt sind, mit dem Attribut 64-Bit versehen (z. B. „64-Bit-Betriebssystem“ oder „Windows 64-Bit“).[1]

Entwicklung[Bearbeiten | Quelltext bearbeiten]

64-Bit-Prozessor
AMD Athlon 64

Die Entwicklung von 64-Bit-Architekturen wurde durch immer preiswerter herstellbaren Hauptspeicher vorangetrieben, die Anfang der 1990er Jahre zu 64-Bit-Architekturen im Serverbereich (MIPS 4000, DEC Alpha, SPARC64, HP PA-RISC, IBM Power 3, Intel IA-64), Anfang der 2000er Jahre im PC/Workstation-Bereich (AMD64) und Anfang der 2010er Jahre selbst im Bereich von Smartphones (ARM64) führte.

Erste Architekturen mit vereinzelten Eigenschaften einer 64-Bit-Architektur gab es ab den 1960er Jahren, so z. B. die IBM 7030 Stretch mit Befehlen mit 32 und 64 bit Breite und mit einer variablen Wortbreite von 1 bis 64 bit sowie mit 64-bit-Gleitkomma-Unterstützung, aber mit nur einem Adressbus, der 218 Worte ansprechen konnte. Hinzu kommen viele andere Prozessoren, die nach heutiger Nomenklatur genauso wenig wie der Pentium P5 (64-bit-Datenbus, Befehle 8 bis 120 bit lang) oder gar der Pentium-4 (hier sogar zwei 64-bit-Datenbusse, über die im Allgemeinen 512-bit-Worte transferiert werden) 64-bit-Architekturen sind, sondern Vektorrechner, die mit Daten versorgt werden wollen.

Frühe Spezial-Architekturen von Supercomputern mit Busbreiten ab 64 bit
  • 1961: die IBM 7030 Stretch mit 18 bit Adressbus und 64 Bit Datenbus und Unterstützung von Worten variabler Bitbreite[2]
  • 1974: der CDC STAR-100 (Nachfolger der 60-Bit-Rechner der Control Data Corporation), ein Vektorrechner in Harvard-Architektur. Mittels 16-bit-Adressbus können bis zu 65536 Superworte à 512 bit über einem 512-bit-Datenbus übertragen werden. Für Befehle gab es einen separaten 128-bit-Bus.
  • 1976: Cray-1, der erste 64-Bit-Vektorrechner, Vorläufer der Cray Supercomputerlinie: 24-bit-Adressraum, 16 oder 32 bit lange Befehle, 16 Datenbusse à 64 bit
  • 1983: Elxsi 6400 sogenannter „Minisupercomputer“ mit 64-Bit-Datenpfaden, 64-bit-Ganzzahlregistern, aber 32-Bit-Adressraum, Unterstützung von Clustern von bis zu 12 CPUs.
64-Bit-Architekturen für Server in Universalprozessoren
64-Bit-Architekturen für Server, PCs, Tabletts und Smartphones in Universalprozessoren
  • 2003: von AMD/​Intel x64, eine Befehlssatzerweiterung für die x86-Prozessorfamilie (16- und 32‑Bit, mit x64 erweitert um 64‑Bit)
  • 2013: von ARM Limited die ARMv8-Architektur

Hardware[Bearbeiten | Quelltext bearbeiten]

Die Architektur eines Prozessors sagt nichts darüber aus, wie einzelne Funktionen konkret im Chipdesign implementiert sind. So können einzelne Befehle im Innern weiterhin als 32-bit-Operationen ausgeführt sein (so wie z. B. Verschiebebefehle in MIPS-R4000-Prozessoren).

Die konkrete Hardware von 64-Bit-Prozessoren ist wesentlich mehr durch das Prozessordesign der Jahre bestimmt, in denen sie eingeführt wurden. Dazu zählen

  • meist Multicore-Systeme
  • meist mehrere 64-bit-Busse zum Hauptspeicher
  • immer Super-Pipelined-Architektur
  • meist Out-Of-Order-Ausführung, superskalare Ausführung
  • meist Vektorbefehle ab 128 bit-Breite
  • Gleitkommaeinheit, die zum Teil mehrere Dutzend Gleitkomma-Befehle pro Core gleichzeitig ausführen können
  • umfangreiche Cache-Architekturen mit 2 bis 3, teilweise 4 Hierarchien
  • Virtualisierungsmöglichkeiten für Speicher und teilweise I/O-Operationen

Der Mehraufwand für die Erweiterung einer 32-bit-Architektur auf 64 bit lag bei etwa 10 Prozent. Der 32-bit-Prozessor Intel Core Duo Processor T2700[4] kam mit 151 Millionen Transistoren aus, der ansonsten weitgehend identische 64-bit-Prozessor Intel Core2 Duo Processor E4300[5] benötigte 167 Millionen. Der Hintergrund ist, dass in den Prozessoren ohnehin schon fast alles 64 bit oder breiter war und nur die allerletzten Komponenten auf 64 bit erweitert werden mussten.

In der PowerPC-Architektur wurde – im Gegensatz zu x86 – die Erweiterung auf 64-Bit von Anfang an vorgesehen, da diese CPU ursprünglich aus dem Bereich der Großrechner (IBM-Power-Architektur) stammt. Auch für die MIPS-Architektur wurde frühzeitig eine 64-Bit-Erweiterung vorgesehen, in beiden Fällen erfolgte die Realisierung als Hardware erst einige Jahre später.

Software[Bearbeiten | Quelltext bearbeiten]

Kompatibilität[Bearbeiten | Quelltext bearbeiten]

Erfolgreiche Universal-64-bit-Prozessoren ermöglichen weiterhin das Ausführen von 32-bit-Code, teilweise von 16-bit-Code. Wird diese Fähigkeit auch durch das 64-bit-Betriebssystem (was zur Ausführung von 64-bit-Programmen notwendig ist) unterstützt, so ist auch dieser ältere Code unter diesen Betriebssystemen (nativ) ausführbar. Dazu müssen Programme im 32-bit-Modus geladen werden können und es muss die 32-bit-API (meist durch einen Wrapper) weiterhin unterstützt werden. So können weiterhin ältere 32-bit-Programme ausgeführt werden, neuere 32-bit-Programme geschrieben und getestet werden. Solange vom Betriebssystem unterstützt, hat man die Auswahl, ob mal 32-bit-Programme oder 64-bit-Programme ausführt.

Im Gegenzug ist es allerdings nicht möglich, 64-bit-Programme unter 32-bit-Betriebssystemen laufen zu lassen, auch auf 64-bit-Prozessoren.

Computerprogramme, die auf eine 64-Bit-Architektur ausgelegt sind, verwenden 64 Bit für die Adressierung des Arbeitsspeichers (bzw. ihres virtuellen Speichers) und sind daher nicht kompatibel zu einer Prozessorarchitektur mit einer niedrigeren Bitzahl (z. B. 32-Bit-Architektur). Andersherum gibt es für einige Plattformen jedoch die Möglichkeit, Programme von 32-Bit-Vorgängersystemen ohne Überarbeitung direkt auf einer 64-Bit-Plattform kompilieren bzw. ablaufen zu lassen. Die AMD64-Prozessoren (einschließlich Intel 64) etwa bieten hierfür einen 32-Bit-x86-Kompatibilitätsmodus. Um dies zu realisieren, enthalten die Prozessoren zusätzliche Komponenten für die Interpretation des 32-Bit-Befehlssatzes. Moderne Betriebssysteme aktivieren diesen Modus für die jeweiligen Prozesse – eine Markierung an der Programmdatei besagt, ob sie im erweiterten 64-Bit-Modus oder im kompatiblen 32-Bit-Modus auszuführen sind. Bei Windows wird dies durch das WOW64-Subsystem realisiert.[6] Wo die Hardware keine Rückwärtskompatibilität anbietet, besteht auch die Möglichkeit, das Ziel der Ausführung von 32-Bit-Programmen über eine vergleichsweise langsame, softwarebasierte Emulation zu realisieren.

Programmiermodell[Bearbeiten | Quelltext bearbeiten]

Unter der Programmiersprache C schlägt sich die Ausrichtung auf einer 64-Bit-Architektur sowohl bei der Größe der Zeiger-Typen (z. B. void *) als auch Integer-Typen (insbesondere int und long) nieder. Beim Übergang von einer 32-Bit-Architektur verbreitert man in der Regel Zeiger und den Datentyp long auf 64 bit, während der Datentyp int auf 32 bit verbleibt. Dieses nennt man dann abgekürzt LP64. Zur Rückwärtskompatibilität mit der 32-Bit-Architektur, die meist als ILP32 ausgeführt wurde, hatte man teils auch long identisch mit int gelassen, was als LLP64 bezeichnet wird. Alle heutigen unixartigen 64-Bit-Betriebssysteme drücken die 64-Bit-Architektur in einem LP64-Typenmodell aus, Windows verwendet das LLP64-Modell.

Das ILP64-Datenmodell wurde eingeführt, da Quellcode von alter Software häufig unter der unzulässigen Annahme entwickelt wurde, dass ein int einen Zeiger halten kann. Es wird auf frühen 64-Bit-Systemen vorgefunden, die schnell auf den Markt wollten, ohne vorher vorhandenen Quellcode bereinigen zu müssen.

64-Bit-Datenmodelle[7]
Daten-
modell
short
(integer)
int
(integer)
long
(integer)
long long
(integer)
pointer
(integer)
Beispiel Betriebssystem/Compiler[8]
LLP64 16 32 32 64 64 Microsoft Win64 (X64/IA64)
LP64 16 32 64 64 64 Unix-Systeme (zum Beispiel Solaris) und Unixoide Systeme (zum Beispiel Linux und macOS)
ILP64 16 64 64 64 64 Cray, DEC/Alpha mit Tru64 UNIX, DEC/Alpha mit Linux
SILP64 64 64 64 64 64 Manche Unicos-Systeme[9]

Vorteile[Bearbeiten | Quelltext bearbeiten]

Der Hauptvorteil von 64-bit-Programmen, die unter einem 64-Bit-Betriebssystem auf einem 64-Bit-Prozessor laufen, ist im Wesentlichen der vergrößerte Adressbereich. Hinzu kommen bei manchen Architekturen (z. B. der x86-64) mehr Universalregister (15 statt 7) und das Gewährleisten von Mindestbefehlssätzen (auch x86-64: man kann sich darauf verlassen, dass SSE2 verfügbar ist). Die Verfügbarkeit von 64-bit-Ganzzahlarithmetik ist für die Adressberechnung von Operanden notwendig und wird für arithmetische Berechnungen heutzutage eher selten benutzt. Arithmetik ist heutzutage meist Gleitkomma-Arithmetik, Graphik-Arithmetik wird in GPUs, meist auch als Gleitkomma-Operationen, ausgeführt. Video-Dekodierung wird z. B. weitgehend in GPUs in dafür spezialisierten Rechenwerken ausgeführt.

Vergrößerter Adressbereich[Bearbeiten | Quelltext bearbeiten]

Der theoretisch mögliche Adressbereich eines 64-bit-Prozessors von 16 Exabyte wird heutzutage meist nicht komplett unterstützt, meist werden nur 48 bit Adressraum pro Prozess (256 Terabyte), einige Server-CPUs unterstützen mittlerweile auch 57 bit (128 Petabyte). Die Einschränkung ergibt sich durch die Stufen der Seitentabellen-Adressauflösung. Ein Adressbereich von mehr als 4 GByte kann schon bei Hauptspeichern weit unterhalb von 4 GByte sinnvoll sein, da

  • der Hauptspeicher durch das Paging um Speicher auf Festplatten oder SSDs erweitert werden kann,
  • Festplattenspeicher direkt in den Speicherbereich von Prozessoren gemappt werden kann und
  • Speicherverwaltung von einem größeren Adressbereich profitiert, weil Daten besser organisiert werden können (Stack und Heap kommen sich nicht in die Quere, die gefürchtete Heap-Fragmentierung tritt nicht auf).

Ein weiterer Vorteil gegenüber einer 32-Bit-Architektur: Es können mehr als vier Gigabyte Arbeitsspeicher direkt adressiert werden (→ 4-GiB-Grenze), wovon Anwendungen mit hohem Speicherbedarf, wie Videoverarbeitung und Datenbanksysteme, profitieren. Mit 64 Bit lassen sich bis zu 16 Exbibyte adressieren, was derzeit (2016) und auf absehbare Zeit ausreichend ist, um nicht nur den verfügbaren Hauptspeicher, sondern auch den Festplattenspeicher (z. B. über mmap) zu adressieren.

Nachteile[Bearbeiten | Quelltext bearbeiten]

Was für datenintensive Programme (beispielsweise bei Datenbank- oder Datei-Servern[10]) ein Vorteil ist, kann besonders bei kleinen Programmen zu Nachteilen hinsichtlich Speicherverbrauch und Geschwindigkeit führen.[11]

Alle Adresswerte sind bei 64-Bit-Architekturen mit 64 Bit doppelt so breit (statt 32 Bit bei den 32-Bit-Architekturen). Ihre Speicherung verbraucht daher im RAM und in den Caches doppelt so viel Platz. Auch andere Datentypen (z. B. long im LP64-Modell) beanspruchen auf 64-Bit-Architekturen doppelt so viel Platz wie auf 32-Bit-Architekturen. Offensichtlich wird dieses in den erzeugten Programmdateien, die im Vergleich zum 32-Bit-Programm typischerweise etwa 25 bis 30 Prozent größer sind[11] und dadurch auch RAM und Cache („Cache miss“) stärker belasten können. Hierdurch wird im ungünstigsten Fall die Ausführungsgeschwindigkeit der Programme um etwa den gleichen Faktor herabgesetzt. Dem wirkt zum Beispiel bei AMD64 (und Intel 64) eine im Vergleich zu IA-32 stark erhöhte Registeranzahl entgegen, sodass auch ungünstige 64-Bit-Programme in der Praxis nicht wesentlich langsamer sind. Auch beherrschen viele 64-Bit-Architekturen eine IP-relative Adressierung mit vorzeichenbehafteten 32-Bit-Offsets, womit eine Zunahme der Befehlslänge verhindert werden kann.

Probleme[Bearbeiten | Quelltext bearbeiten]

Ohne speziell angepasste Ausführungsumgebung kann allerdings kein Vorteil durch den Wechsel von 32-Bit- auf 64-Bit-CPUs gezogen werden. Dies wird insbesondere bei abwärtskompatiblen CPUs wie AMD Athlon 64 X2, AMD Phenom X3/X4, Intel Pentium D, Intel Pentium Extreme Edition, Intel Core 2 Duo, Intel Core 2 Quad, Intel Core i7 oder den 64-Bit-PowerPC-CPUs deutlich. Dies betrifft nicht nur die Betriebssysteme mit 64-Bit-Systemkern zur Paging-Verwaltung mit großen Adressen, sondern auch die Hilfsbibliotheken der Programme mit den darin eingesetzten Algorithmen: Viele alte Systeme verwenden 32-Bit-optimierte Algorithmen, die erst nach Anpassung durch Programmierer von der 64-Bit-Erweiterung profitieren.

Die Notwendigkeit der Anpassung betrifft im Anwendungsbereich besonders mathematische Hilfsfunktionen (auch Multimedia und Spiele), aber auch die Speicherverwaltung. Viele Programme aus dem Unix-Bereich haben hierbei einen Vorsprung, da dort 64-Bit-Architekturen schon lange üblich sind. Über die Entwicklung der Workstations wurden im Unixbereich (einschließlich Linux) auch Desktopprogramme schon langjährig auf 64 Bit angepasst, bevor die Windowsprogramme auf die 64-Bit-Editionen von Windows angepasst wurden. Bei macOS ist die Entwicklung gemischt, da der Unix-basierte Kern und die Desktopoberfläche aus verschiedenen Entwicklungszweigen stammen. Gerade letztere Systeme machen dabei Gebrauch von der Möglichkeit der abwärtskompatiblen CPUs, auf einem 64-Bit-Betriebssystemkern sowohl 32- als auch 64-Bit-Programme parallel auszuführen – diese haben jedoch das Problem, dass die Wechselwirkung der Programme auf dem Desktop gehemmt sein kann (bekannt etwa für Browser-Plugins).

Ähnlich wie bei SIMD oder AltiVec-Erweiterungen ist also auch für 64-Bit-Systeme in der Regel speziell angepasste Software nötig.

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. Harry Phillips: New Perspectives on Microsoft Windows Vista for Power Users. Cengage Learning, 2008, ISBN 978-1-4239-0603-2, S. 16 (eingeschränkte Vorschau in der Google-Buchsuche).
  2. Unterlagen zum IBM 7030 Stretch
  3. PA-RISC 2.0 Architecture Specifications, ftp.parisc-linux.org (englisch, PDF-Datei)
  4. https://ark.intel.com/products/27238
  5. https://ark.intel.com/products/28024
  6. Jorge Orchilles: Microsoft Windows 7 Administrator's Reference: Upgrading, Deploying, Managing, and Securing Windows 7. Syngress, 2010, ISBN 978-1-59749-562-2, S. 9 (eingeschränkte Vorschau in der Google-Buchsuche).
  7. 64-Bit Programming Models: Why LP64? The Open Group, 1998, abgerufen am 1. Januar 2016 (englisch).
  8. Das Datenmodell ist eine Eigenschaft des Compilers unter dem entsprechenden Target-Betriebssystems, nicht des Betriebssystems allein.
  9. Cray C/C++ Reference Manual. Cray Inc, abgerufen am 2. Januar 2016 (englisch).
  10. Mehr Performance: Linux mit 64-Bit-Programmen. Detaillierter Vergleich von 32-Bit- und 64-Bit-Anwendungsbenchmarks unter Linux.
  11. a b Are 64-bit Binaries Really Slower than 32-bit Binaries?, Englisch, Vergleich von 32-Bit- und 64-Bit-Programmen auf Solaris/SPARC.