Prozessorbau im Hardware-Software-Codesign - Moderne Prozessorarchitekturen: Prinzipien und ihre Realisierungen - page 288

elle Befehlsfolge einzeln geschehen, wodurch die Interpretation jedoch verlangsamt
würde. Im Allgemeinen verwendet man deshalb konstante, durch Messung an
Benchmark-Programmen ermittelte Grenzwerte.
4.2.2 Separation
Falls die Laufzeitumgebung mit dem darin eingebetteten Interpreter eine virtuelle
Befehlsfolge durch Vergleich des mit der jeweiligen Sprungmarke assoziierten Zäh-
lers und des konstanten Grenzwerts als Übersetzenswert erkannt hat, wird sie durch
Binärübersetzung in eine reale Befehlsfolge umsetzt, und zwar entlang des bisher
am häufigsten ausgeführten, hier als separiert bezeichneten Programmpfads ( hot
trace ). Dieser lässt sich mit den über das Laufzeitverhalten im Trace-Cache gesam-
melten Profildaten auf einfache Weise bestimmen. Zum Beispiel wurde die virtuelle
Nemesis-Befehlsfolge in Bild 4.9, ausgehend von der Sprungmarke L1, wenigstens
dreimal, von der Sprungmarke L2 jedoch nur zweimal ausgeführt, sodass der virtu-
elle Sprungbefehl in Zeile 5 allem Anschein nach bisher häufiger verzweigt als nicht
verzweigt ist. Des Weiteren findet sich im Trace-Cache kein Eintrag zur Sprung-
marke L3, woraus man ableiten kann, dass der virtuelle Sprungbefehl in Zeile 9 bis-
her kein einziges Mal verzweigte. Zusammenfassend lässt sich somit feststellen,
dass der binär zu übersetzende Programmpfad dem grau unterlegten Bereich folgt.
Bemerkung. Der separierte Programmpfad wird hierbei mit Hilfe einer Heuristik nicht exakt
ermittelt. Möglicherweise verzweigt der virtuelle Sprungbefehl in Zeile 5 tatsächlich nie, wenn
nämlich die Sprungmarke L2 zuvor zweimal das Ziel eines hier nicht dargestellten virtuellen
Sprungbefehls war. Diese Ungenauigkeit lässt sich jedoch in Kauf nehmen, weil zu den meisten
Sprungmarken nur ein einziger Sprungbefehl führt.
Selbstverständlich ist es auch möglich, den in der Vergangenheit am häufigsten ausgeführten Pro-
grammpfad exakt zu ermitteln. Dazu muss neben dem Trace-Cache ein Sprungcache in Software
implementiert werden, in dem die Häufigkeit, mit der Sprungbefehle verzweigen bzw. nicht ver-
zweigen, gezählt wird. Der Programmpfad lässt sich dann sehr einfach separieren, indem man
jeweils den bisher häufigeren Sprungentscheidungen folgt. Nachteilig an diesem Verfahren ist
jedoch, dass für den Sprungcache zusätzlicher Speicher benötigt wird und sich die zur Profilerstel-
lung notwendige Interpretation verlangsamt. In seiner Funktion entspricht ein Sprungcache übri-
gens einem in Hardware realisierten Sprungvorhersagecache (siehe Abschnitt 2.2.5).
Natürlich muss zur Separation eines Programmpfads noch dessen Ende festgelegt
werden. Am einfachsten geschieht dies, indem man die Anzahl der virtuellen
Befehle, virtuellen Sprungbefehle oder verzweigenden virtuellen Sprungbefehle
konstant begrenzt, oder indem die virtuelle Befehlsfolge solange binär übersetzt
wird, wie sie innerhalb eines vorgegebenen Speicherbereichs liegt. Das letztge-
nannte u.a. mit Daisy von IBM implementierte Verfahren ist vor allem deshalb von
Vorteil, weil sich damit die in virtuellen Programmen codierten Befehlsadressen
linear in reale Befehlsadressen umsetzen lassen, was die Binärübersetzung deutlich
vereinfacht [34, 35].
Ein weiteres sehr durchdachtes Verfahren beschreibt Gschwind et.al. in [53]: Der
Programmpfad endet hierbei, wenn der letzte codierte Befehl mit einer Wahrschein-
lichkeit zur Ausführung gelangt, die unter einem konstanten Grenzwert größer Null
liegt. So berechnet sich z.B. die Wahrscheinlichkeit dafür, dass die in Bild 4.9 auf