Information Technology Reference
In-Depth Information
Solange dies noch nicht geschehen ist, werden alle virtuellen Sprungziele L3 in die
realen Sprungziele V4 umgesetzt, was einen Zugriff auf den Trace-Cache erfordert.
Bemerkung. Eine bisher ungeklärt gebliebene Frage ist die nach dem Umgang mit indirekten vir-
tuellen Sprungbefehlen. Da hier das virtuelle Sprungziel erst zur Laufzeit feststeht, ist das direkte
oder indirekte Binden in der zuvor beschriebenen Weise nicht möglich. Die einfachste Lösung
besteht in der Verwendung einer stop-Operation, der als Argument das indirekte Sprungziel überge-
ben wird. Bei Ausführung wird in die Laufzeitumgebung zurückgekehrt und anhand der als Argu-
ment übergebenen virtuellen Sprungadresse nach einem geeigneten Trace-Cache-Eintrag gesucht.
Falls er gefunden wird, kommt es zum Aufruf der assoziierten realen VLIW-Befehlsfolge. Andern-
falls beginnt, wie gewohnt, die Interpretation der an der Zieladresse stehenden virtuellen Befehle.
Problematisch ist dieses Vorgehen im Zusammenhang mit den indirekt arbeitenden virtuellen
Unterprogrammrücksprungbefehlen, weil diese nämlich sehr häufig auftreten und daher die Aus-
führungsgeschwindigkeit signifikant mindern würden. Da hier jedoch oft nur wenige potentielle
Sprungziele in Frage kommen, wird normalerweise so verfahren, dass man vor der stop-Operation
die virtuelle indirekte Sprungadresse mit bereits bekannten virtuellen Zieladressen vergleicht und
bei Gleichheit das assoziierte reale Sprungziel direkt ansteuert. So entspricht die VLIW-Befehls-
folge in Bild 4.12 links z.B. dem indirekten virtuellen Sprungbefehl rechts (mit jeweils zwei paral-
lel auszuführenden Operationen pro Befehl). Die virtuellen Sprungziele L1 und L2 wurden bei der
Profilbildung identifiziert und bei der Binärübersetzung direkt an die realen Trace-Buffer-Einträge
V1 und V2 gebunden.
cmp
r3, #L1;;
cmp
r3, #L2
beq
V1;;
bra
[r3]
beq
V2;;
stop
[r3];;
Bild 4.12.
Umsetzung eines indirekten virtuellen Sprungbefehls in eine VLIW-Befehlsfolge
4.2.6 Speicherbereinigung (garbage collection)
Damit der Trace-Cache schnell nach einem passenden Eintrag durchsucht werden
kann, ist er i.Allg. mit einer konstant begrenzten Anzahl von Einträgen realisiert.
Daraus resultiert aber auch, dass größere virtuelle Programme sich nicht vollständig
binärübersetzt darin halten lassen. Gegebenenfalls müssen beim Binärübersetzten
eines neu hinzukommenden virtuellen Programmpfads deshalb Inhalte aus dem
Trace-Cache ersetzt werden. Als Vorteilhaft erweist sich dabei, dass jüngere, durch
Binärübersetzung erzeugte reale Befehlsfolgen meist besser an das aktuelle sich
dynamisch ändernde Laufzeitverhalten angepasst sind als ältere, durch Binärüber-
setzung erzeugte reale Befehlsfolgen. Selbst wenn die vorgesehene Kapazität aus-
reicht, um ein virtuelles Programm vollständig binärübersetzt aufnehmen zu kön-
nen, ist es oft besser, Inhalte von Zeit zu Zeit aus dem Trace-Cache zu entfernen,
anstatt sie dauerhaft darin zu speichern, um nämlich eine Neuübersetzung bereits
binärübersetzter Befehlsfolgen nun unter Berücksichtigung eines aktualisierten
Laufzeitprofils zu erzwingen.
Programmierte Verfahren
Das Entfernen eines einzelnen Eintrags ist wegen der gebundenen Trace-Buffer-Ein-
träge sehr kompliziert. Angenommen, der grau unterlegte Eintrag des Trace-Buffers
Search WWH ::
Custom Search