Information Technology Reference
In-Depth Information
hierbei jeweils auf den nach dem Sichern oder Laden neuen ältesten Eintrag des
Registerspeichers zu setzen.
Ob das Sichern bzw. Laden von Registerinhalten programmiert innerhalb eines Aus-
nahmeprogramms oder eigenständig durch den Prozessor erfolgt, hängt von der
jeweiligen Implementierung ab. Gebräuchlicher ist es, Inhalte eigenständig durch
die Hardware zwischen Registerspeicher und Datenspeicher zu transferieren. Dies
geschieht z.B. beim Itanium 2 von Intel [75, 78], der 128 Register besitzt, von denen
zu jedem Zeitpunkt 32 global und 96 lokal adressierbar sind. Die lokalen Register
sind als Stapel organisiert, der für den Benutzer unsichtbar im Datenspeicher fortge-
setzt wird.
Ein weiteres Beispiel für einen Prozessor mit Registerstapel ist der Nemesis C der
TU Berlin (und zwar in der Version 1.0). Er verfügt über insgesamt 96 physikalische
Register, von denen jedoch nur 16 zu einem Zeitpunkt direkt zugreifbar sind. Je
nach Einstellungen können dies acht globale und acht lokale oder 16 lokale Register
sein. Eine Besonderheit dabei ist, dass der Registerspeicher im Adressraum das
Datenspeichers eingebettet ist und indirekt adressiert werden kann [114, 112]. So ist
es möglich, in Registern Variablen zu halten, die über Zeiger oder Referenzen adres-
siert werden. Dies ist vor allem deshalb ein Vorteil, weil die in einigen Program-
miersprachen häufig verwendete Parameterübergabe per Referenz keine Sonderbe-
handlung erfordert. Selbst beim nicht mehr gefertigten Am29000 von AMD [1], der
64 globale und 128 als Stapel organisierte lokale Register besitzt und der einen indi-
rekten Zugriff auf Registerinhalte erlaubt, ist eine Fallunterscheidung bei der Dere-
ferenzierung von Variablen notwendig, um nämlich festzustellen, ob die adressierte
Variable sich im Register- oder im Datenspeicheradressraum befindet.
Die Organisation des Registerspeichers in Fenstern oder als Stapel ist sinnvoll, weil
es auf diese Weise möglich ist, einen Kontextwechsel bei den oft notwendigen
Unterprogrammaufrufen schnell durchzuführen. Natürlich setzt dies voraus, dass
der Registerspeicher ausreichend groß ist, um die lokalen Variablen und die Auf-
rufparameter geschachtelter und in Bearbeitung befindlicher Unterprogramme
gleichzeitig darin halten zu können. Bei einem Prozesswechsel ist daher eine grö-
ßere Anzahl an Registern zu sichern bzw. zu laden, als wäre der Registerspeicher
„flach“ organisiert.
Nun ist es prinzipiell möglich, den Registerspeicher in Bänken und die Bänke in
Fenstern oder Stapeln zu organisieren, um durch einfaches Umschalten der Regis-
terbank einen schnellen Prozesswechsel zu ermöglichen. Nachteil einer solchen
Lösung ist jedoch, dass es nicht möglich ist, ungenutzte Register, die einem Prozess
zugeordnet sind, durch einen anderen Prozess zu nutzen. Besser wäre es daher,
wenn die Register den Prozessen dynamisch zugeteilt werden könnten, wie dies z.B.
mit der in Bild 1.23d angedeuteten Registerorganisation möglich ist.
Der physikalische Registerspeicher ist hierbei in Bänken unterteilt, die neben den
Registern (im Bild vier Register pro Bank) einen Zeiger auf eine beliebige Register-
bank enthalten. Zu Beginn sind die Registerbänke zunächst in einer Liste verkettet,
deren erster Eintrag über den im Spezialregister Free befindlichen Inhalt adressiert
wird und deren letzter Eintrag z.B. durch einen Nullzeiger gekennzeichnet ist. Benö-
Search WWH ::
Custom Search