Verzögerungsschlitz - Delay slot
In der Computerarchitektur ist ein Verzögerungsschlitz ein Befehlsschlitz, der ohne die Auswirkungen eines vorhergehenden Befehls ausgeführt wird. Die häufigste Form ist eine einzelne willkürliche Instruktion unmittelbar nach einer Verzweigungsanweisung auf einer RISC oder DSP - Architektur; dieser Befehl wird ausgeführt, selbst wenn die vorhergehende Verzweigung genommen wird. Daher scheinen die Anweisungen konstruktionsbedingt in einer unlogischen oder falschen Reihenfolge ausgeführt zu werden. Es ist typisch für Assembler , Anweisungen standardmäßig automatisch neu anzuordnen, um die Unbeholfenheit vor Assemblyentwicklern und Compilern zu verbergen.
Verzweigungsverzögerungsschlitze
Wenn ein Verzweigungsbefehl beteiligt ist, kann die Stelle des folgenden Verzögerungsschlitzbefehls in der Pipeline als Verzweigungsverzögerungsschlitz bezeichnet werden . Verzweigungsverzögerungsschlitze werden hauptsächlich in DSP- Architekturen und älteren RISC- Architekturen gefunden. MIPS , PA-RISC , ETRAX CRIS , SuperH und SPARC sind RISC-Architekturen, die jeweils einen einzelnen Verzweigungsverzögerungsschlitz aufweisen; PowerPC , ARM , Alpha und RISC-V haben keine. Zu den DSP- Architekturen mit jeweils einem einzelnen Branch-Delay-Slot gehören VS DSP , μPD77230 und TMS320C3x . Der SHARC DSP und MIPS-X verwenden einen Double Branch Delay Slot; ein solcher Prozessor führt nach einem Verzweigungsbefehl ein Paar von Befehlen aus, bevor die Verzweigung wirksam wird. Der TMS320C4x verwendet einen Triple Branch Delay Slot.
Das folgende Beispiel zeigt verzögerte Verzweigungen in Assemblersprache für den SHARC DSP einschließlich eines Paares nach dem RTS-Befehl. Die Register R0 bis R9 werden der Reihe nach auf Null gelöscht (das nach R6 gelöschte Register ist R7, nicht R9). Kein Befehl wird mehr als einmal ausgeführt.
R0 = 0;
CALL fn (DB); /* call a function, below at label "fn" */
R1 = 0; /* first delay slot */
R2 = 0; /* second delay slot */
/***** discontinuity here (the CALL takes effect) *****/
R6 = 0; /* the CALL/RTS comes back here, not at "R1 = 0" */
JUMP end (DB);
R7 = 0; /* first delay slot */
R8 = 0; /* second delay slot */
/***** discontinuity here (the JUMP takes effect) *****/
/* next 4 instructions are called from above, as function "fn" */
fn: R3 = 0;
RTS (DB); /* return to caller, past the caller's delay slots */
R4 = 0; /* first delay slot */
R5 = 0; /* second delay slot */
/***** discontinuity here (the RTS takes effect) *****/
end: R9 = 0;
Das Ziel einer Pipeline-Architektur besteht darin, in jedem Taktzyklus einen Befehl abzuschließen. Um diese Rate beizubehalten, muss die Pipeline jederzeit mit Anweisungen gefüllt sein. Der Verzweigungsverzögerungsschlitz ist ein Nebeneffekt von Pipeline-Architekturen aufgrund der Verzweigungsgefahr , dh der Tatsache, dass die Verzweigung nicht aufgelöst würde, bis der Befehl seinen Weg durch die Pipeline gearbeitet hat. Ein einfaches Design würde nach einem Verzweigungsbefehl Blockierungen in die Pipeline einfügen, bis die neue Verzweigungszieladresse berechnet und in den Programmzähler geladen ist . Jeder Zyklus, in dem eine Blockierung eingefügt wird, wird als ein Verzweigungsverzögerungsschlitz betrachtet. Ein ausgeklügelterer Entwurf würde Programmbefehle ausführen, die nicht vom Ergebnis des Verzweigungsbefehls abhängig sind. Diese Optimierung kann in Software zur Kompilierzeit durchgeführt werden, indem Befehle in Verzweigungsverzögerungsschlitze im In-Memory-Befehlsstrom verschoben werden, wenn die Hardware dies unterstützt. Ein weiterer Nebeneffekt ist, dass eine spezielle Behandlung erforderlich ist, wenn Breakpoints auf Anweisungen verwaltet werden und während des Debuggens innerhalb des Verzweigungsverzögerungsslots schrittweise gearbeitet wird .
Die ideale Anzahl von Verzweigungsverzögerungsschlitzen in einer bestimmten Pipeline-Implementierung wird durch die Anzahl der Pipeline-Stufen, das Vorhandensein von Registerweiterleitung , welche Stufe der Pipeline die Verzweigungsbedingungen berechnet werden, ob ein Verzweigungszielpuffer (BTB) verwendet wird, diktiert und viele andere Faktoren. Anforderungen an die Softwarekompatibilität schreiben vor, dass eine Architektur die Anzahl der Verzögerungsschlitze von einer Generation zur nächsten nicht ändern darf. Dies erfordert unweigerlich, dass neuere Hardwareimplementierungen zusätzliche Hardware enthalten, um sicherzustellen, dass das Architekturverhalten befolgt wird, obwohl es nicht mehr relevant ist.
Ladeverzögerungs-Slot
Ein Ladeverzögerungsschlitz ist ein Befehl, der unmittelbar nach einem Laden (eines Registers aus dem Speicher) ausgeführt wird, aber das Ergebnis des Ladens nicht sieht und nicht darauf warten muss. Ladeverzögerungsschlitze sind sehr selten, da Ladeverzögerungen auf moderner Hardware sehr unvorhersehbar sind. Eine Last kann vom RAM oder von einem Cache erfüllt werden und kann durch Ressourcenkonkurrenz verlangsamt werden. Bei sehr frühen RISC-Prozessordesigns wurden Lastverzögerungen beobachtet. Der MIPS I ISA (implementiert in den R2000- und R3000- Mikroprozessoren) leidet unter diesem Problem.
Das folgende Beispiel ist MIPS I-Assembly-Code, der sowohl einen Ladeverzögerungs-Slot als auch einen Branch-Delay-Slot zeigt.
lw v0,4(v1) # load word from address v1+4 into v0
nop # wasted load delay slot
jr v0 # jump to the address specified by v0
nop # wasted branch delay slot