Untergrenze des Füllstandes

Der Scheduler wählt einen Thread nur dann zur Bearbeitung aus, wenn sich eine bestimmte minimale Anzahl von Bytes im Befehlsfenster dieses Thread befindet. Diese Anzahl ist mindestens eins, da aus einem leeren Fenster nichts ausgeführt werden kann. Man kann sie aber auch auf höhere Werte festlegen.

Die Festlegung der Untergrenze auf drei bringt leichte Verbesserungen des Ergebnisses, insbesondere bei kleinem Befehlsfenster, wie in Abbildung 3.6, oder bei hohem Anteil an Speicherbefehlen. Die Anzahl der Leerzyklen wird verringert, da eher ein nicht so hoch priorisierter Thread ausgeführt wird, der aber sicher ausgeführt werden kann, als der höchstpriorisierte, wenn dieser zu einem Unterlaufen seines Befehlsfensters führen könnte.

Abbildung 3.6: Die Leerlaufzeit bei verschiedenen Untergrenzen

Das führt natürlich dazu, daß ein exklusiv laufender Thread benachteiligt wird, da es vorkommen kann, daß sich nur ein Byte im Befehlsfenster befindet, so daß der Scheduler den Thread nicht ausführt, auch wenn es sich um einen Befehl handelt, der nur ein Byte lang ist. Dies kommt aber selten vor, weil in diesem Fall auch nur Befehle für diesen einen Thread aus dem Speicher geladen werden, das Fenster also meistens sehr voll ist.

Es gibt also drei Möglichkeiten, mit der Untergrenze umzugehen:

• Weglassen: Da die erreichbare Verbesserung maximal zwei Prozent beträgt, ist es fraglich, ob sich hierfür ein größerer Hardwareaufwand lohnt.
• Erweitern: Man könnte den Simulator so umbauen, daß ein Thread, der nicht genug Bytes in seinem Befehlsfenster hat, trotzdem ausgeführt wird, wenn er der einzige ist, der überhaupt ausführbar ist.

Das würde allerdings die folgende Variante unmöglich machen:

• Beibehalten: Man kann die Grenze so einstellen, daß ein Thread erst ausgeführt wird, wenn wenigstens drei Bytes im Befehlsfenster stehen. Der zusätzliche Hardwareaufwand rechtfertigt sich dann dadurch, daß man Logik in der Decode-Stufe einsparen kann. Diese kann dann nämlich davon ausgehen, daß das Befehlsfenster des momentan ausgewählten Thread auf jeden Fall genügend Daten enthält. Dieser Umstand wird bei der Einordnung des Schedulers in die Pipeline des Mikrocontrollers in Abschnitt 4.3 noch genauer betrachtet.

Für die späteren Versuche über Latenzen und Echtzeitverhalten wird diese Grenze daher auf drei festgelegt.