Allgemeiner Aufbau der SPARC

Speicherworte und Register sind 32 oder 64 bit breit, über die genaue Art des Bussystems, der Caches und weiterer implementationsabhängiger Systemteile gibt die Definition keine Auskunft, da, wie bereits angesprochen, SPARC eine Instruction-Set-Architecture ist und somit den Herstellern in allen Fragen der Implementation freie Hand läßt.

Eigenschaften der FPU

Die FPU arbeitet parallel, nicht notwendigerweise synchron, zur IEU, d.h. daß eine einmal angestoßene Operation der FPU bis zu ihrem Abschluß die Operationen der IEU nicht unterbricht oder verzögert. Eine SPARC FPU besitzt 32 Register zu je 64 bit, die wie folgt verwendet werden können:

32 32-bit Register (Half Word)
32 64-bit Register (Word)
16 128-bit Register (Double Word)

Um die Eigenschaften der FPU genau zu beschreiben, wurden die IEEE Standards 754 (32bit Floating Point Processing) und 1596.5 (64bit Floating Point Processing) verwendet, die von jeder SPARC Version 9 konformen FPU erfüllt werden.

Die Integer Execution Unit

Die Integer Execution Unit (IEU) ist das zentrale Rechenwerk der SPARC Architektur. Sie ist zuständig für alle Integer- und Adressberechnungen. Da SPARC eine RISC Architektur ist, existiert kein Microcode. Alle Instruktionen werden in einem Taktzyklus ausgeführt (One-Instruction-per-Cycle) und alle Speicherzugriffe geschehen RISC-typisch nur durch Load/Store Operationen. Die SPARC-Architektur besitzt eine Pipeline mit Interlock, d.h. daß die Prozessorpipeline den Zugriff auf die Zielregister von Load/Store Operationen solange verzögert, bis die Daten korrekt aus dem Hauptspeicher geladen wurden.

Status- und Kontrollregister der IEU

Die SPARC V9 Architektur beschreibt 25 Register, die für die Steuerung und Kontrolle des Prozessorzustandes unbedingt vorgesehen und damit fest definiert sind. Hierzu gehören neben dem Prozessor Status Register auch Program Counter, Trap Register und Registerfenster Steuer- und Statusregister, wie in Tabelle 1 aufgelistet. Neben diesen fest definierten Registern können je nach Prozessorimplementierung weitere Register optional eingesetzt werden.

General Purpose Registers

SPARC Prozessoren besitzen ein Current Window Pointer Register, das auf das jeweils aktive Registerfenster des Prozessors verweist. Obwohl alle SPARC Register wenigstens 32 bit breit sind, werden nur 5 bit des CWP Registers verwendet, was zur Folge hat, daß maximal 32 Registerfenster adressierbar sind. Somit besitzen SPARC Prozessoren maximal 32 Registerfenster zu jeweils 16 Registern, sowie 8 globale Register. Die Definition schreibt unter anderem ein Minimum von 3 Registerfenstern vor, das konforme Prozessoren besitzen. Die User-Software kann von diesen maximal 520 Registern jeweils nur 32 Register adressieren, nämlich 8 incoming Register, 8 outgoing Register, 8 lokale Register sowie die 8 globalen Register.

SPARC General Purpose Register Windows

Wie im folgenden Abschnitt gezeigt wird, sind immer 3 Registerfenster in Verwendung, so daß nur die Anzahl der Registerfenster-2 für Funktionen verwendbar sind (daher resultiert auch die Forderung nach mindestens 3 Registerfenstern). Dadurch, daß sich die Frames der outgoing- und incoming-Register überschneiden, wird die Verwendung des Speicherstacks bei Funktionsaufrufen und Traps reduziert. Nur wenn eine Funktion oder Trap mit mehr als 8 Argumenten aufgerufen wird, muß ein Window Fill/Spill-Trap ausgeführt werden, der einem konventionellen Zugriff auf einen Stack entspricht. Window Fill/Spill ist auch notwendig, wenn die Anzahl der verwendeten Registerfenster größer der Anzahl der verfügbaren Registerfenster ist. Hierbei werden ganze Registerfenster in den Hauptspeicher ausgelagert und bei Bedarf wieder eingelagert. Dies geschieht durch einen hochprioren Hardware-Trap (siehe Abschnitt Traps und Interrupts). Wie in Bild 2 dargestellt, reduziert der Window-Overlap, die Verwendung eines speicherbasierten Stacks. Aufgrund der Untersuchungen von Patterson/Hennessey um 1980 wurden die quantitativ nachgewiesenen Größen von Funktions- und Prozeduraufrufen zur Auslegung der Registerframes und -fenster verwendet.

Register Window Management mit Register Window State Registern

Das Management der Register Windows geschieht vollständig unter der Kontrolle der Hardware, was ausschließt, daß Registerfenster überschrieben oder übersprungen werden. Ein Wechseln des Registerfensters geschieht durch die SAVE Instruktion, die den Inhalt eines Registerfensters sichert und den Current Window Pointer (CWP) inkrementiert. Sollten keine freien Registerfenster verfügbar sein, so kommt es zu einem Window Spill/Fill Trap, der den Inhalt eines Registerfensters in den Hauptspeicher auslagert. Hier werden die Inhalte der Registerfenster wie in einem normalen LIFO-Stack gehalten. Um zu erkennen, wann Registerfenster verfügbar sind, bzw. wann ein Window Spill/Fill Trap ausgelöst wird, existieren die Zeigerregister Restoreable Windows Register, Savable Windows Register und Other Windows Register. Restorable Windows Register enthält die Anzahl der Registerfenster, die vom momentanen Programm verwendet werden können, ohne daß RESTORE einen Window Fill Trap auslöst. Savable Windows Register enthält die Anzahl der Registerfenster, die nicht aktuell verwendet werden, und somit ohne Window Spill Trap verfügbar sind. Other Windows Register enthält die Anzahl der Windows, die mit Spill/Fill ein- bzw. ausgelagert werden sollen.

SPARC Register Window Management (8 Registerfenster)

Trap Management und Trapping

Um Traps verwenden zu können, müssen zunächst von der Systemsoftware die Trap Handler installiert werden. Hierzu wird das Trap Base Register der SPARC Version 9 Hardware mit der Startadresse des Trap Handling Codes beschrieben. Im Trap Type Register ist für den jeweiligen Trap der Offset des Trap Handlers festgelegt, der beschreibt, wie weit der Handler von der im Trap Base Register festgelegten Startadresse entfernt ist. Dieser Offset besteht aus jeweils 8 Instruktionen, 32 Instruktionen für Window spill/fill Traps, die von den Trap Handlern mitgenutzt werden können. Die hieraus resultierende Adresse wird auch als Trap Vektor bezeichnet. Der Vorteil dieser Methode besteht darin, daß eventuell mit diesen 8 bzw. 32 Instruktionen Sprünge im Trap Handling Code reduziert oder vermieden werden können. Da Traps des Typs 1, also System Calls und Interrupt Handler die Majorität der Traps ausmachen, wurden mit SPARC V9 Fast-Traps eingeführt.

Trap Vektoren

Hierbei wird nicht wie bisher in Version 7 und 8 üblich für jeden Trap ein Registerfenster der General Purpose Register verwendet, sondern es existieren zusätzlich 8 Alternalte Global Registers, die exklusiv für Trap Level 1 Code reserviert sind. Durch Fast-Traps werden zusätzliche Window spill/fill Traps vermieden, bzw. reduziert, da diese 8 Register immer verfügbar sind.

Registerverwendung beim Trapping

Deferred Traps

Bei den direkten Traps wird ein Trap vor Abschluß einer Instruktion und der damit verbundenen Zustandsänderung des Prozessors ausgelöst.
Um den Durchsatz in der Pipeline zu erhöhen und Wartezeiten bei der Instruktionsbearbeitung zu vermeiden, können Instruktionen beendet werden und den Prozessorzustand ändern bevor alle Auswirkungen auf das System bekannt sind. Erzeugt eine solche Instruktion nach ihrer Beendigung einen Trap, so spricht man von deferred Traps, da die erforderliche Ausnahmebehandlung erst nach der Zustandsänderung des Prozessors einsetzen kann. Beispiele für deferred Traps sind Speicheroperationen, bei denen während der Instruktionsausführung nicht klar ist, ob die Operation korrekt beendet wird, da sie eventuell erst einige Zyklen nach der Instruktionsbearbeitung zum Abschluß kommt. Statt dessen muß in diesem Fall der Prozessorzustand vor der Instruktionsausführung gesichert werden, um bei Bedarf den Prozessor wieder in seinen ursprünglichen Zustand (Zustand vor Beginn der Instruktion) zurücksetzen zu können. Die zu sichernde Zustandsmenge ist von der Tiefe der Pipeline und der Verzögerung der Operationen abhängig. Um den Prozessorzustand zuverlässig wiederherstellen zu können, erlaubt SPARC keine Verzögerung von Traps über neue Traps hinaus. Sonst können z.B. die Registerfenster gewechselt, oder I/O durchgeführt werden, was den alten Systemzustand nicht mehr reproduzierbar macht. Nachteil von verzögerten Traps ist, daß die alten Prozessorzustände gesichert werden müssen, was nur durch das Speichern der Registerinhalte, und somit einer erhöhten Speicherkapazität der CPU möglich ist. Der entscheidende Vorteil von verzögerten Traps ist, daß die nachfolgenden Instruktionen bereits abgearbeitet werden können, obwohl eine vorhergehende Operation noch nicht vollständig abgeschlossen wurde. Die Verwendung von deferred Traps ist in der SPARC Definition Version 9 optional.

Instruktionsformate

Die Länge einer Instruktion ist immer 32 bit. Die SPARC Instruktionsformate können grob in 4 verschiedene Kategorien gegliedert werden, die wiederum aus mehreren Unterformaten bestehen. Die bits 30 und 31 bilden das op-Feld, das beim Instruction Predecoding verwendet wird.

SPARC Version 9 Instruktionsformate

Instruktionen

Insgesamt besitzt der SPARC Version 9 Instruktionssatz 82 fest definierte Integer-Instruktionen. Zu diesen kommen je nach Implementierung bis zu 5 herstellerdefinierte Integer-Instruktionen hinzu. Neu am Instruktionssatz ist, daß in Branch Instruktionen ein 1 bit p-Feld existiert, das angibt, ob eine Branch verfolgt wird oder nicht. Neu ist auch die Gruppe der Conditional Move Operationen MOVcc, MOVr, FMOVcc und FMOVr, die, abhängig von Condition Codes (cc) bzw. Registerinhalten (r), Inhalte von Source-Registern verschieben. Z.B. kann der C-Ausdruck

Multiprozessor Synchronisationsprimitive

Die bereits in SPARC Version 8 vertretenen Multiprozessor Synchronisationsprimitive wurden an die neue Architektur angepaßt. Die Barrier Instruktion STBAR wurde zu MEMBAR, der 64 bit Variante. Obwohl hiermit wechselseitiger Ausschluß programmiert werden kann, existieren weitere, atomare, Instruktionen zum direkten wechselseitigen Ausschluß.

Total Store Order (TSO)

Das Speichermodell Total Store Order definiert, daß alle Store Operationen, also alle Schreiboperationen in den Hauptspeicher in der Reihenfolge ihrer Initiierung, also in Order ausgeführt werden müssen. Leseoperationen in den Hauptspeicher werden in der Reihenfolge ihrer Initiierung ausgeführt und sind zudem blockierend. D.h. daß aufeinanderfolgende Leseoperationen solange blockieren, bis die Zielregister beschrieben sind. Schließlich sind die atomaren Load/Store Operationen sowohl bezüglich Load- als auch Store Operationen geordnet.
Der Einsatzbereich von TSO ist hauptsächlich auf Single-Prozessor-Rechner beschränkt, da die Einschränkungen dieses Modells im Multiprozessorbetrieb hohe Wartezeiten bedeuten. Total Store Order ist ein Auslaufmodell in der SPARC-Architektur, da TSO nur aus Kompatibilitätsgründen zu den SPARC Versionen 7 und 8 besteht und in künftigen SPARC Definitionen wahrscheinlich nicht mehr vorkommt.

Partial Store Order (PSO)

Bei dem Speichermodell Partial Store Order sind die Load Operationen untereinander, sowie die atomaren Load/Store Operationen bezüglich der Load Operationen geordnet. Load Operationen sind wie in TSO blockierend, Schreiboperationen sind jedoch nicht geordnet. Auch PSO ist ein Auslaufmodell, wird jedoch wahrscheinlich später als TSO aus den SPARC-Definitionen entfernt.
Alle Programme, die korrekt im PSO Speichermodell arbeiten, arbeiten zudem auch korrekt im TSO Speichermodell.

Relaxed Memory Order (RMO)

Relaxed Memory Order legt bei Speicherzugriffen keine Ordnung fest, mit Ausnahme derer, die für die Konsistenz des Prozessors nötig sind. D.h., daß der Programmierer/Compiler für die Anordnung der Speicherzugriffe verantwortlich ist. Dies ist besonders im Multiprozessorbetrieb vorteilhaft, da der Programmierer die Semantik der Operationen überblickt, und nur in notwendigen Fällen die Speicherzugriffe steuert. Diese Steuerung geschieht explizit mittels MEMBAR Instruktionen, die die Zugriffe auf Speicherbereiche bis zum Abschluß der Operation blockieren kann. Da im Relaxed Memory Order Speichermodell keine Ordnung der Speicheroperationen garantiert ist, arbeiten alle Programme, die korrekt im RMO Speichermodell ablaufen auch korrekt im PSO Speichermodell und somit auch korrekt im TSO Speichermodell. Programme die im RMO Modell korrekt arbeiten, arbeiten sowohl im PSO- als auch im TSO Modell korrekt.

SPARC Speichermodelle

Programme die im PSO Modell korrekt arbeiten, arbeiten auch im TSO Modell korrekt. Neue Programme sollten, da PSO und TSO in Zukunft nicht mehr unterstützt werden, bereits jetzt nach den Anforderungen des Relaxed Memory Order Modell entwickelt werden.

UltraSPARC II - Architectural Overview

Aufgrund der geringen Transistoranzahl besitzt der UltraSPARC-2 Prozessor keine Out-Of-Order-Execution-fähigkeit. Um Synchronisationsprobleme in der Pipeline zu vermeiden operiert die FPU des UltraSPARC-2 synchron zur IEU, d.h. mit einer 9-stufigen Pipeline mit 3 Wartezyklen (siehe Bild 9). Auch bei der Branch-Prediction, verwendet Sun einen einfachen Ansatz. Die Branch-Prediction-History ist 2 bit tief, mit der folgenden Funktion

9-stufige Pipeline des Sun UltraSPARC-2 Prozessors

Visual Instruction Set (VIS TM)

Das Visual Instruction Set, eine Prozessorerweiterung, die nicht in der SPARC Definition vorkommt, ist ein ähnlicher Ansatz, wie MMX bei Intel. Die FPU übernimmt mit einem erweiterten Instruktionssatz zusätzliche Aufgaben. Diese beschränken sich auf 64-bit RGBa-Berechnungen. Hierbei wird jeder Bildpunkt in 4x16 bit codiert (16 bit jeweils für Rot, Grün, und Blau, sowie 16 bit Alphablending). Auf diesem 64-bit Wort wird dann eine SIMD Berechnung ausgeführt. Das Ergebnis wird FPU-typisch von der IEU wieder gelesen, bzw. in neue Speicherbereiche geschrieben.

VIS Instruktionen (2)

Weitere Instruktionen zum Vergleichen, Transformieren, Multiplizieren und Dividieren von Pixelpacks und 8-bit, 16-bit, und 32-bit Teilworten sind verfügbar. Hiermit können komplexe Operationen, z.B. packed -> planar, ausgeführt werden. Nachteil ist wie auch bei MMX, daß während der Ausführung von VIS-Instruktionen die verwendeten Register der FPU nicht für eigentliche Floating Point Operationen zur Verfügung stehen. Da die SPARC FPU 32 64-bit Register besitzt, ist hier jedoch das Aufteilen der Register auf VIS-Instruktionen und Floating Point Instruktionen einfacher zu handhaben.

SPARC64-GP Architectural Overview

Im Gegensatz zum Sun UltraSPARC-2 Prozessor besitzt der SPARC64-GP zwei Integer Functional Units, eine für Fixed-Point Integer Operationen, eine weitere für Fixed-Point Integer Operationen und Adressoperationen. Jede dieser Einheiten besteht aus zwei ALSs (Arithmetic Logic Shift Units), die parallel zueinander operieren. Zudem besitzt der Prozessor zwei Floating-Point Einheiten die aus jeweils einem Floating-Point Multiply-Adder und einem Floating-Point Divider bestehen, so daß bis zu 4 Floating-Point Operationen parallel ausgeführt werden können. Um auch hier Out-Of-Order Operationen zu unterstützen, besitzen die FPUs die in SPARC Version 9 definierten 32 Floating-Point Register, sowie weitere 32 Rename Register. Zwei Load-/Store-Units, die für eine durchschnittliche Beschleunigung des Speicherdurchsatzes um den Faktor 1.5 im Vergleich zu einer LSU, verantwortlich sind beliefern den Prozessor mit Instruktionen und Daten. Im Gegensatz zur Sun UltraSPARC operieren die FPUs nicht synchron zur IEU, sondern besitzen eine nur 4 Cyclen tiefe Pipeline. Der Fujitsu/HAL SPARC64-GP besitzt keine On-Chip MMU, was durch die Verwendung mehrstufiger TLBs ausgeglichen wird. So besitzt der SPARC64-GP drei TLBs mit je 32 Einträgen, einen für Instruktionen und zwei TLBs für Daten, sowie TLBs mit 256 Einträgen ebenfalls sowohl für Instruktionen wie für Daten. Hiermit unterstützt der SPARC64-GP Seitengrößen des Speichers zwischen 4 KByte und 4GByte. Außerdem wurde ein sogenannter Level-0 Cache für Instruktionen eingeführt, der 16 KByte groß ist und zwischen Instruktion-Buffer und Level-1 Cache angesiedelt ist. Insgesamt legten die Entwickler des SPARC64-GP stärkeren Wert auf eine permanent gefüllte und operierende Pipeline, was viele große Caches, parallele Einheiten und eine hochentwickelte 2-stufige Branch-Prediction Unit zur Folge hat. Circa 11 Millionen der 17,5 Millionen Transistoren des Prozessors werden in Caches und Puffern eingesetzt. Um die Größe des Prozessor-dies so zu gestalten, daß er in der Ultra-Port-Architecture (UPA), einer von Sun definierten Prozessor-Bus Schnittstelle, eingesetzt werden kann, verzichtete man auf eine On-Chip MMU. Sie ist als externer Chip mit weiteren, beschleunigenden Eigenschaften, wie getrenntem Memory- und Cache-Bus und vergrößerten TLBs implementiert.

Vergleich der Leistungsdaten

Trotz der Vielzahl gemeinsamer Parameter, sind die Prozessoren jedoch nicht wirklich vergleichbar. Suns Prozessor ist für den Bereich der Hochleistungs-Workstation gebaut worden, der HAL-Prozessor ein echter Server Prozessor, z.B. auch ohne VIS. Da speziell RISC-Rechner von hochentwikkelten Compilern profitieren, die die Nutzung der Pipeline optimieren, ist der SPARC64-GP zwar auf dem Papier einem UltraSPARC-2 Prozessor überlegen, da er die Ordnung des Programmcodes in Hardware reorganisiert, hochentwickelter und optimierter Code benötigt diese Reorganisierung aber kaum, da Code Reorganisation faßt nur bei schlechten Compilern, altem Code oder bei Floating Point Instruktionen verwendet wird.

[SPARC 1994]

David L.Weaver, Tom Germond: SPARC Architecure Manual Version 9, SPARC International, Prentice-Hall

[SPARC 1987]

David L. Weaver: SPARC Architecture Manual Version 8, Sparc International, Prentice-Hall

[Tanenbaum 1990]

Andrew S. Tanenbaum: Structured Computer Organization, Prentice-Hall International

[HAL 1998]

SPARC64-GP, HAL/Fujitsu, http://www.hal.com/

[Sun 1997]

SPARC Users Manual, 1997, Sun Microsystems, http://www.sun.com/