Information Technology Reference
In-Depth Information
sage indirekter Sprungziele mit einem in dieser Art realisierten Sprungzielcache ist
gering [22, 21], weshalb man ihn in einigen Prozessoren nur für Vorgriffe auf
direkte Sprungziele verwendet.
Verzögerte Eintragsersetzung in Sprungzielcaches. Mit Einführung der objekto-
rientierten Programmierung hat der Einfluss korrekter Vorhersagen von indirekten
Sprungzielen auf die Gesamtlaufzeit entsprechender Programme deutlich an Bedeu-
tung gewonnen, da die oft verwendeten virtuellen Methoden indirekt über Tabellen
aufgerufen werden, die den einzelnen Klassen statisch zugeordnet sind [22, 15]. Die
Verwendung eines einfachen Sprungzielcaches ist hier vorteilhaft, wenn ein
bestimmter Sprungbefehl vorrangig zu immer derselben Zieladresse indirekt ver-
zweigt. Sobald jedoch ein von diesem Hauptsprungziel abweichender Sprung ein
einzelnes Mal ausgeführt wird, kommt es zu zwei Fehlvorhersagen: eine, wenn zum
neuen Sprungziel, und eine, wenn zum Hauptsprungziel verzweigt wird. Letzteres
deshalb, weil mit der vom Hauptsprungziel abweichenden zuvor verwendeten Ziel-
adresse der Sprungzielcache aktualisiert wurde.
Calder, Grunwald und Lindsay schlugen in [21] deshalb vor, eine im Sprungzielca-
che eingetragene Zieladresse nur dann zu ändern, wenn sie sich mehrere Male hin-
tereinander als falsch erwiesen hat (siehe auch [33]). Dies lässt sich ähnlich wie bei
der dynamischen Sprungvorhersage durch Gewichtung mit Hilfe eines auf- und
abwärts zählenden Sättigungszählers erreichen. Bei jeder Fehlvorhersage wird der
Zähler inkrementiert, bei jeder korrekten Vorhersage dekrementiert. Falls der Zähl-
wert einen Maximalwert erreicht, wird das neue Sprungziel in den Sprungzielcache
eingetragen, sonst nicht.
Pfad- oder Entscheidungshistorie in Sprungzielcaches. Die Zieladressen indirek-
ter Verzweigungen sind genau wie die Entscheidungen bedingter Sprungbefehle von
der Vorgeschichte des aktuell ausgeführten Programms abhängig. Deshalb ist es
möglich, indirekt codierte Sprungziele abhängig von den Zieladressen vorangehend
ausgeführter Sprungbefehle vorherzusagen (sie werden zusammengefasst als
Sprungpfad bezeichnet).
Die prinzipielle Funktionsweise des Verfahrens ist in Bild 2.44 dargestellt. Ein indi-
rekt codiertes Sprungziel wird vorhergesagt, indem man zunächst den im Register
PHR ( path history register ) gespeicherten Sprungpfad benutzt, um auf die als Cache
realisierte Pfadhistorientabelle zuzugreifen (a). Der dort gespeicherte Eintrag wird
direkt für die Vorhersage des Sprungziels verwendet (b). Steht das tatsächliche
Sprungziel kurze Zeit später fest, kommt es zur Aktualisierung der Pfadhistorienta-
belle und des im Register PHR gespeicherten Sprungpfads (c). Letzteres geschieht,
indem die tatsächliche Zieladresse oder ein Teil davon, meist die unteren ein bis drei
relevanten Bits, in das als Schieberegister realisierte Register hineingeschoben wer-
den. Mit den im Bild angegebenen Einträgen adr 1 bis adr 3 wird z.B. nach Aktuali-
sierung als nächstes das Sprungziel adr 2 vorhergesagt (d).
Genau wie die Verfahren zur adaptiven Sprungvorhersage lassen sich auch hier
zahlreiche Modifikationen vornehmen, um Detailverbesserungen zu erreichen. So
kann die Pfadhistorie über alle Sprungbefehle gemeinsam ( global ) oder separat zu
jedem einzelnen Sprungbefehl ( lokal ) gespeichert werden. Sie lässt sich durch
Search WWH ::




Custom Search