Information Technology Reference
In-Depth Information
Beispiel 1.15. Verwaltung von Registerfenstern . Registerfenster für Unterprogrammaufrufe sind
u.a. in den Prozessoren der SPARC-Familie, z.B. dem UltraSPARC IIIi von Sun im Einsatz [173].
Je nach Implementierung können zwischen acht und 32 Registerfenster mit jeweils acht Registern
für den Eingangs-, den lokalen und den Ausgangsbereich in einem Prozessor realisiert sein. Des
Weiteren stehen acht globale Register zur Verfügung, so dass zu jedem Zeitpunkt 32 Register direkt
zugreifbar sind (in den Befehlen sind dementsprechend fünf Bit breite Registeradressen codiert).
Das aktuelle Registerfenster wird durch den fünf Bit breiten sog. Current-Window-Pointer ( CWP )
selektiert, der im privilegierten Supervisor-Modus direkt und im weniger privilegierten Benutzer-
modus durch Ausführung der Befehle save und restore verändert werden kann. Die Befehle benutzt
man, um nach einem Unterprogrammaufruf ein neues Registerfenster zu reservieren oder es vor
einem Unterprogrammrücksprung freizugeben. Damit die Schachtelungstiefe nicht durch die tat-
sächlich Anzahl vorhandenen Registerfenster beschränkt werden muss, wird ähnlich verfahren, wie
zu den Registerbänken beschrieben, wobei nicht das am längsten belegte, sondern das letzte beleg-
bare freie Registerfenster durch ein Bit in der sog. Window-Invalid-Mask gekennzeichnet wird.
Falls bei Ausführung eines save-Befehls das markierte Registerfester aktiviert werden soll, wird
statt dessen ein sog. Window-Overflow-Trap ausgelöst. Der Prozessor reagiert auf diese Ausnahme-
anforderung, indem er das markierte (leere) Registerfenster aktiviert, die Rücksprungadressen in
den lokalen Registern %l1 und %l2 sichert (siehe hierzu Abschnitt 1.4.1) und in das zuständige
Ausnahmeprogramm verzweigt. Anschließend wird der Inhalt des ältesten belegten Registerfens-
ters (es folgt auf das markierte Registerfenster) programmiert in den Datenspeicher übertragen und
als letztes leeres Registerfenster markiert. Mit dem Rücksprung in das unterbrochene Programm
wird der save-Befehl erneut ausgeführt, diesmal jedoch ohne eine Ausnahmeanforderung zu verur-
sachen. Ähnlich verfährt man mit einem ein markiertes Registerfenster aktivierenden restore-
Befehl, nur dass dabei der Inhalt des entsprechenden Registerfensters nicht im Datenspeicher gesi-
chert, sondern aus dem Datenspeicher geladen wird.
Die statische Unterteilung des Registerspeichers in Fenster fester Größe hat den
Vorteil einfach realisierbar zu sein, jedoch den Nachteil, oft die durch das Unterpro-
gramm gestellten Anforderungen entweder überzuerfüllen oder ihnen nicht zu genü-
gen. Sollen z.B. beim UltraSPARC IIIi weniger als acht Parameter übergeben wer-
den, so bleiben einige der dafür vorgesehenen Register ungenutzt. Ist es andererseits
notwendig, mehr als acht Parameter zu übergeben, werden zusätzliche globale
Register oder Datenspeicherzellen benötigt.
In einigen modernen Prozessoren ist der Registerspeicher deshalb nicht in Fenstern,
sondern als Stapel entsprechend Bild 1.23c organisiert. So kann genau die Anzahl
an Registern reserviert bzw. freigegeben werden, die benötigt wird bzw. wurde,
indem der Stapelzeiger Window-Base dekrementiert bzw. inkrementiert wird.
Natürlich ist die maximale Anzahl der pro Unterprogramm nutzbaren Register auf
die Anzahl der vorhandenen physikalischen Register begrenzt. Es ist aber möglich,
jedem einzelnen Unterprogramm diese maximale Anzahl zur Verfügung zu stellen,
und zwar auch bei geschachtelten Unterprogrammaufrufen.
Hierzu muss der physikalische Registerspeicher ringförmig adressiert und der Sta-
pelzeiger bei jedem Dekrementieren bzw. Inkrementieren daraufhin überprüft wer-
den, ob er den durch Tail adressierten ältesten Eintrag des Registerspeichers kreuzt.
Sollte dies der Fall sein, muss bei einem Unterprogrammaufruf alles zwischen dem
neuen Stapelzeigerwert in Window-Base und Tail gesichert und bei einem Unterpro-
grammrücksprung aus dem Datenspeicher geladen werden. Der Inhalt von Tail ist
Search WWH ::




Custom Search