{"id":18282,"date":"2025-07-11T20:11:27","date_gmt":"2025-07-11T18:11:27","guid":{"rendered":"https:\/\/www.bernd-leitenberger.de\/blog\/?p=18282"},"modified":"2025-07-12T08:51:39","modified_gmt":"2025-07-12T06:51:39","slug":"die-glorreichen-10-computerarchitekturen-1","status":"publish","type":"post","link":"https:\/\/www.bernd-leitenberger.de\/blog\/2025\/07\/11\/die-glorreichen-10-computerarchitekturen-1\/","title":{"rendered":"Die glorreichen 10 – Computerarchitekturen (1)"},"content":{"rendered":"
<\/div>\n

<\/path><\/svg><\/i> \"Loading\"<\/p>\n

<\/div>\n

Heute wieder ein kurzweiliger, trotzdem informativer Blog in meiner locken Reihe „Die Glorreichen 10<\/a>„, angelehnt an das gleichnamige Fernsehformat von ZDFneo. Es geht um Elemente von Computerarchitekturen also Dingen die den Rechner schneller oder besser machten.<\/p>\n

Ich will mich von dem Ranking lösen, also keine Platzierung wie „1-ter Platz“ vergeben und das aus einem guten Grund – es hängt von dem jeweiligen Computer ab. Ein kleines Beispiel: In der x86 Entwicklung<\/a> brachte die Einführung der Pipeline den größten Performancesprung nämlich 250 Prozent beim Übergang vom 8086<\/a> zum 80286<\/a>. Der nächste Sprung – die Einführung des Caches beim 80386<\/a> brachte nur 160 Prozent Geschwindigkeit (so zu verstehen = alte Architektur = 100 %). Langfristig ist der Cache aber der Teil der den Prozessor am stärksten beschleunigt. Der Grund liegt daran, dass langfristig die Geschwindigkeit von Arbeitsspeicher kaum gesteigert wurde. Heute kann DRAM Daten mit einer Verzögerung von 7 bis 10 ns liefern. Das ist zwar 15-mal schneller als 1986, als der 80386 eingeführt wurde<\/a>, der Takt steig in derselben Zeit aber um den Faktor 300 bis 400. Ein zweiter Grund ist, dass es auch von der Anwendung abhängt. Heute haben alle PC Vektoreinheiten. Wären sie nicht da, der normale PC Nutzer würde nichts bemerken. Supercomputer<\/a> die dieselben Prozessoren einsetzen, würden aber auf einen Bruchteil ihrer Leistung zurückfallen.<\/p>\n

Also legen wir los. Ich weiß, dass es Blogleser gibt, die sich in der Materie noch besser als ich auskennen, ich versuche aber aus didaktischen Gründen und Platzgründen mich auf das Wichtigste zu beschränken. Also habt Verständnis, wenn alles sehr einfach erklärt ist und ihr noch viel dazu beitragen könntet. (Wie wäre es mit einem Gastartikel?) Wer mehr wissen will – es gibt eine ganze Sektion zu dem Thema<\/a> auf der Website. Und ja ich kann bei 10 Punkten nicht alles hereinnehmen, es gäbe noch einiges mehr zu erwähnen, wie VLIW \/ Branch Prediction.<\/p>\n

Obwohl ich mich für meine Verhältnisse kurz fasse, ist der Artikel doch zu lang für einen Blog geworden, daher heute die ersten fünf Stichwörter und morgen die nächsten fünf.<\/a><\/p>\n

Von Neumann – Harvard Architektur<\/h4>\n

Sehr früh in der Geschichte des Computers musste man festlegen, wie der Speicher genutzt wird. Jeder Computer verarbeitet Programme, also Code und die Programme verarbeiten wiederum Daten. Es gibt nun zwei Ansätze wie man den Speicher zwischen Code und Daten aufteilt: Die von Neumann Architektur hat einen gemeinsamen Speicher für Daten und Code. Beide Ansätze sind sehr alt und entstanden schon bei den ersten Computern: Die Harvard Architektur 1944 beim Mark I und die von Neumann Architektur wurde gleich mehrfach entdeckt und sowohl von Zuses Z3<\/a>, wie auch dem ersten US-Computer ENIAC eingesetzt. John von Neumann fungiert, obwohl er die Theorie erst 1945 aufstellte, trotzdem als Namensgeber, weil vorher man sie einfach umsetzte aber nicht benannte<\/p>\n

Die Harvard Architektur hat dagegen getrennte Speicher für Daten und Code. Beide Ansätze sind weit verbreitet. Pcs oder Smartphones haben Prozessoren mit der von Neumann Architektur<\/a>, da wo die Prozessoren versteckt sind, also in Geräten wie Waschmaschine oder MP3-Player, dominiert die Harvard Architektur. Die von Neumann Architektur hat den Vorteil, dass die beiden Teile Daten und Code variabel sind. Beispiel auf dem PC: Eine Textverarbeitung hat viel Code, die meisten verfassen damit aber eher kurze Texte, also wenige Daten. Eine Videobearbeitung verarbeitet dagegen Videos, also sehr große Datenmengen. Daneben braucht man bei der von Neumann-Architektur nur einen Datenbus, was die Pins die ein Prozessor hat deutlich verringert. Die Harvard Architektur trennt die beiden Busse. Sie können auch unterschiedlich groß sein und unterschiedliche Architekturen haben. Mikrocontroller mit der Harvard Architektur haben meist einen sehr kleinen Codespeicher aus DRAM und einen größeren Datenspeicher in Form von Flash-ROMs. Ein Vorteil ist auch das so der Codespeicher geschützt ist. Code kann sich so nicht selbst modifizieren.<\/p>\n

Risc – CISC<\/h4>\n

Ein zweiter Ansatz eine Architektur aufzustellen liegt in den Befehlen. Sie können sehr elementar sind (RISC<\/a> – Reduced Instruction Set) oder sehr komfortabel (CISC – Complex Instruction Set). Ein Beispiel: in Zählschleifen hat man oft die Befehlsfolge Dekrementiere Register und Springe wenn Register=0. Dies können zwei Befehle sein (RISC) oder einer (CISC). RISC benötigt weniger Transistoren für eine Architektur, auch weil die Anzahl der Befehle und ihre Leistung großen Einfluss auf die Größe und Komplexität der internen Einheiten eines Prozessors hat. CISC ist, wenn dies keine Rolle spielt meist schneller. Da zumeist mit jeder Generation neue Befehle aufgenommen werden, neigen auch RISC-Architekturen<\/a> dazu zu CISC zu werden. So waren die weit verbreiteten ARM Prozessoren mal RISC-Prozessoren, doch 30 Jahre nach der Einführung sind sie das nicht mehr.<\/p>\n

Heute dominiert RISC noch in dem Segment wo der Preis sehr wichtig ist, bei Microcontrollern. In den späten Achtzigern sah man in RISC die Option einen 32-Bit-Prozessor zu designen und die Aufwendungen dafür zu begrenzen, indem er nicht komplexer als ein 16 Bit CISC-Prozessor<\/a> ist. Das ermöglichte es Firmen die nicht die Marktmacht von Intel oder Motorola hatten, einen Prozessor einzuführen.<\/p>\n

Microcode<\/h4>\n

Wenn ein Befehl im Prozessor ankommt, gelangt er in den Dekoder und das Steuerwerk in denen das Bitmuster Aktionen auslöst. Diese Teile sind bei einfachen Prozessoren wie z.B. den 8-Bit-Prozessoren meist hardware-verdrahtet. Heute setzen alle größeren Prozessoren Microcode ein. Microcode<\/a> ist ein ROM im Prozessor. Der Decoder liefert eine Adresse im ROM und dann wird das Bitmuster für einen Befehl – nicht eines, sondern meist mehrere nacheinander aus dem ROM geholt und an das Steuerwerk gesendet. Dabei können auch Schleifen und Verzweigungen realisiert werden. Ein Befehl für das Kopieren eines Blocks kann z.B. in einen Einzelkopierbefehl und eine Schleife zerlegt werden.<\/p>\n

Der Vorteil ist, dass man so sehr komplexe Befehle realisieren kann, ohne ein komplexes Steuerwerk und einen komplexen Dekorder zu haben. Bessere Architekturen erlauben auch das Austauschen des Inhalts eines Microcode-ROM, man kann so Fehler beseitigen oder den Microcode verbessern, das geht heute sogar über das Internet, war aber schon (allerdings nur mit physischen Zugriff auf den Baustein) in den Siebzigern möglich, was die Herstellung eines Prozessors oder ein Update deutlich vereinfachte.<\/p>\n

Der Nachteil ist, dass Microcode langsamer als die direkte Verdrahtung ist weil er einen Zwischenschritt einschiebt. Bei dem IBM System \/360 war es z.B. so, dass die meisten Systeme bis auf die schnellsten Microcode einsetzten, nur die schnellsten waren hardwarekodiert. Bei dieser Linie zeigte sich auch ein anderer Vorteil von Microcode: die gesamte Serie verarbeitete denselben Programmcode, die interne Architektur variierte aber und so auch der Mikrocode, der im ROM war. Das Einstiegssegment hatte eine 16-Bit-Architektur mit wenigen Kilobyte RAM, das Endsegment 32-Bit-Architektur und bis 1 MByte RAM.<\/p>\n

Pipelines<\/h4>\n

Die Ausführung eines Befehls durchläuft im Prozessor mehrere Phasen die unterschiedlich lang sein können und bei komplexen Befehlen sich auch wiederholen können:<\/p>\n