Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 3 » CISC/RISC   (Übersicht)

  • Prüfer: Prof. Fey
  • Beisitzer: Franz Richter

CISC/RISC

P: Wir haben CISC kennengelernt. Wie sieht so eine Architektur aus?

Mikroprogramm-Leitwerk gezeichnet und erklärt

P: Was sind denn die Vorteile, die man durch die Mikroprogrammierung hat?

Updates für Bugfixes, Abwärtskompatibilität mit älteren Architekturversionen, Emulation komplett anderer Architekturen

P: Wieso ist man dann zu RISC gegangen?

Bei CISC wurden viele Befehle gar nicht verwendet, also wird aufwändige Steuerlogik nicht ausgenutzt. Außerdem ist CISC schwer zu pipelinen, da stark unterschiedlich lange Befehle.

P: Wie sieht dann eine RISC-Architektur aus?

Alle Befehle sind gleich lang, Load/Store Architektur (Register sind Operanden, plus spezielle Load/Store Befehle), keine komplexe Adressierungsmodi, indirekte Adressierung muss also explizit ausgerechnet werden.

P: Was haben CISC Befürworter an RISC kritisiert?

Weil alle Befehle in RISC gleich lang sind, verschwendet man bei manchen Instruktionen Platz, bspw. eine Operation die keine Operanden hat, könnte in CISC in einem Byte kodiert werden, hat unter RISC aber trotzdem die volle Breite.

P: Was ist ein weiterer Nachteil, der z.B. durch das Fehlen von komplexer Adressierung in RISC entsteht?

Programme sind unter RISC tendenziell länger, da indirekte Adressierung eben explizit gemacht werden muss.

Pipelining

P: Was ist dann der Vorteil, eine Pipeline einzusetzen?

Im besten Falle bis zu k-facher Speedup bei k Pipeline Stufen.

P: Wieso erreicht man diesen Speedup in der Praxis nicht? Was gibt es für Probleme?

Struktur-, Steuerungs-, Datenhazards. Strukturhazard erklärt, Steuerungshazard erklärt.

P: Wie viele Zyklen verliert man bei einem unbedingten Sprung in der Pipeline?

Einen, da das Sprungziel erst nach dem Dekodieren bekannt ist. Währenddessen muss die Befehl-holen-Phase also stallen.

P: Was gibt es für verschiedene Datenhazards?

RAW und WAW erklärt, zu WAR ein Beispiel hingeschrieben:

R0 = R1 / R2
R3 = R0 + R4
R4 = 3

RAW-Hazard zwischen den ersten beiden Instruktionen, die 2. blockiert, dadurch entsteht bei out-of-order execution erst der WAR-Hazard zwischen 2. und 3. Instruktion.

P: Zur Vermeidung von Datenhazards gibts das Scoreboard. Wie funktioniert das? (Legt Blatt mit Scoreboard-Algorithmus aus Vorlesung hin)

Nach und nach die verschiedenen Stufen erklärt, und wann welcher Hazard vermieden wird. Hier war eine relativ detaillierte Beschreibung erforderlich: Warum wird in Stufe 2 gewartet, bis die Flags Rj, Rk beide 1 sind? Wann und wieso sind die Flags nach Stufe 1 eins? Warum werden die Flags von Stufe 2 nach 3 auf 0 gesetzt? Wie funktioniert die Warte-Bedingung in Stufe 4?

P: Es geht noch besser als Scoreboard.

…ja, mit Tomasulo. Hier vermeidet man WAW und WAR-Hazards durch Registerumbennenung. Reservierungsstationen erklärt, erklärt, wie Befehle eingelastet werden, woher die Operanden kommen (Werte aus Registerfile oder Referenzen auf die entsprechenden Reservierungsstationen → das eigentliche Renaming).

Cachebewertung

P: Okay, mal was anderes. Wir haben uns mit Cache-Bewertung beschäftigt. Wie sieht denn die Formel für die mittlere Cachezugriffszeit aus?

T = Th + m * Tm (Th = Zeit bei Hit, m = Missrate, Tm = Nachladezeit bei Miss)

P: Durch welche Maßnahmen kann man die Missrate verbessern?

Größere Caches, höherer Assoziativitätsgrad. Leider steigt dadurch Th.

P: Und wie kann man Th verkleinern?

Genau umgekehrt: kleinere Caches, niedriger Assoziativitätsgrad. Dann steigt wieder die Missrate.

P: Was ist mit der Nachladezeit bei Miss?

Neues Cachelevel einführen, die Zeit für Zugriff zwischen Cache und Speicher verkürzt.

P: Wie verändert sich dann die Formel für die Zugriffszeit?

Tm besteht wieder aus obiger Formel, nur für das tiefere Cachelevel.

P: Welchen Einfluß hat denn die Blockgröße auf die Missrate?

Je größer die Blockgröße, desto niedriger die Missrate.

P: Hm. Können sie da mal eine Kurve zeichnen, auf y-Achse die Missrate, auf x-Achse die Blockgröße.

Ich wusste nicht mehr genau, wie die Kurve aussieht. Ich habs mal mit einer logarithmischen Kurve versucht. Prof. Fey und mir fällt gleichzeitig auf, dass das keinen Sinn macht; die Kurve muss abfallen. Auch die abfallende Kurve ist noch nicht ganz richtig: Die Missrate steigt irgendwann wieder leicht an. Wenn die Blöcke zu groß sind, steigt die Wahrscheinlichkeit, dass man unnütze Daten in den Cache lädt, die man gar nicht mehr liest.

Multicore

P: Gut, schon 25 Minuten sind rum, schnell noch zu Multicore. Wieso haben wir denn überhaupt Multicore?

In Vergangenheit wurde Leistungssteigerung hauptsächlich durch Steigerung der CPU-Frequenz erreicht. Die können wir nicht mehr unbegrenzt steigern. Mit höherer Frequenz steigt die Leistungsaufnahme, also die Temperatur. Es gibt eine Belastungsgrenze, die das Material maximal aushält. Zweitens durch Architekturverbesserungen. Aber Pollacks-Regel (Leistungssteigerung ist proportional zu Wurzel der Komplexitätssteigerung) sagt, dass wir für eine Verdopplung der Logik nur 1,4 mal so viel Leistung bekommen. Also auch hier ausgereizt.

P: Durch was für Architekturverbesserungen hat man denn Leistungssteigerung erreicht?

Pipelining, SIMD, größere Caches.

P: Ja, und auch Sprungvorhersage. Wie gut ist man da so?

95% Trefferquote

P: Da kann man nicht mehr so viel rausholen. Also was hat man stattdessen gemacht?

Pollacks-Regel quasi rückwärts angewandt. Halbieren der Logik erbringt immernoch 70% der Leistung. Zwei dieser Chips haben also 140% der Leistung, bei gleicher Fläche.

P: Dann wärs doch gut, diese Aufteilung immer weiter zu treiben. Wieso macht man das nicht?

Ein bisschen Single-Core-Performance zu haben ist schon gut, schließlich kann man nicht perfekt parallelisieren.

P: Das auch. Und was setzt eine harte Grenze?

Naja, kleiner als bis auf 1-Transistor-Chips kann man nicht gehen.

P: Welche erfolgreiche Architektur zeigt aber doch, dass die Aufteilung in kleine Chips erfolgreich ist?

GPUs. Da haben wir kleine Shader, die eigentlich nur noch aus ALU bestehen.

Eingebettete Prozessoren

P: Die 30 Minuten sind eigentlich rum.. Erklären sie doch noch mal in kurzen Worten, was der Unterschied zwischen Universalprozessor, ASIC und FPGA ist.

Universalprozessor kann alles, ist flexibel, teuer, hat hohen Leistungsverbrauch. ASIC kann nur eine Sache, da festverdrahtet, ist aber leistungsstark und energieeffizient, weil man sich die Pipeline usw. spart. Da er günstig ist, kann man ihn auch in hohen Stückzahlen feststellen. Ein FPGA ist quasi ein rekonfigurierbarer ASIC, der Leistungsverbrauch ist etwas höher, er ist etwas teurer.

P: Und wie erreicht man die Rekonfigurierbarkeit beim FPGA?

Gitterförmig angeordnete Einheiten, in die man über lookup-tables jede beliebige Logikfunktion programmieren kann. Flip-Flops zum speichern, und auf dem Gitter-Kreuzungspunkten kann man schalten, wie die Daten fließen.

Die Prüfung lief entspannt ab, Note war sehr gut. Ein paar kleinere Zwischenfragen hab ich vergessen. Wenn ich mal länger was erzählt hab, fand ich es schwer, aus Prof. Fey zu lesen, ob das was ich sage, stimmt oder nicht. Davon nicht verunsichern lassen ;-)