{"id":15814,"date":"2022-03-06T15:20:41","date_gmt":"2022-03-06T14:20:41","guid":{"rendered":"https:\/\/www.bernd-leitenberger.de\/blog\/?p=15814"},"modified":"2022-03-06T15:21:18","modified_gmt":"2022-03-06T14:21:18","slug":"intel-prozessoren-bei-denen-es-anders-lief-als-geplant","status":"publish","type":"post","link":"https:\/\/www.bernd-leitenberger.de\/blog\/2022\/03\/06\/intel-prozessoren-bei-denen-es-anders-lief-als-geplant\/","title":{"rendered":"Intel-Prozessoren, bei denen es anders lief als geplant"},"content":{"rendered":"
<\/div>\n

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

<\/div>\n

Nach Intels Flops die ich gestern vorgestellt habe, heute ein weiterer Beitrag zu dem Thema. Diesmal geht es um Prozessoren \/ Architekturen bei denen die Geschichte anders lief, als von Intel geplant, auch wenn man in den meisten Fällen nicht von einem kommerziellen Fehlschlag sprechen kann.\"\"<\/p>\n

Intel 8086<\/h3>\n

Wie schon geschrieben ging Intel nach dem 8080<\/a> gleich den nächsten Prozessor an, diesmal gleich ein großer Wurf, der 8800, später in iAPX 432<\/a> umbenannt. Sehr bald zeigte sich das die Entwicklung Jahre dauern würde und bis dahin konnte die Konkurrenz natürlich ihre eigenen Prozessoren auf den Markt bringen. So entschloss man sich doch noch einen 16 Bit Prozessor dazwischenzuschieben als \u201eLückenbüßer\u201c. Man fragte die Kunden und die wollten vor allem Kontinuität, das bedeutet ihre existierende 8080-Software musste leicht an den neuen Prozessor anpassbar sein. Da man auch in Zeitnot war, schließlich hatte man sich zuerst auf den 8800 konzentriert, fällte Intel die Entscheidung, das der neue Prozessor 8086<\/a> im Prinzip eine 16 Bit Version des 8080 sein sollte. Er hatte dieselbe Zahl an Allzweckregistern, verwendete wie dieser die Zweiadressadressierung, sodass das AX Register immer das Ziel von Rechenoperationen war, sogar alle 8080 Befehle waren als Untermenge vorhanden. Ein Programm konnte maschinell Assemblercode des 8080 in Binärcode des 8086 übersetzen.<\/p>\n

Der Ansatz der Kompatibilität ist ja gut, aber Intel setzte einige Hindernisse, die nicht nötig waren. Da die Register nur 16 Bits breit waren, konnte der Prozessor auch nur 64 KB direkt adressieren \u2013 zu wenig für einen 16 Bitter. Um einen größeren Adressraum zu bekommen, addierte man den um 4 Bits verschobenen Wert eines Segmentregisters bei der Adressierung und konnte so die 64 KB wie Fenster in einem 1 MB großen Adressraum verschieben. Wer in PC-Zeiten mal unter DOS programmiert hat, kennt die Folgen: Datenstrukturen wie Arrays waren so auf 64 KByte beschränkt, außer man legte sie dynamisch zur Laufzeit an, globale Daten ebenfalls auf 64 KB. Das war umständlich und das machten die Konkurrenten besser.<\/p>\n

Zum Verhängnis sollte werden, das IBM den Prozessor wählte<\/a> und sich ihr IBM PC zum Industriestandard durchsetzte<\/a>. Das bedeutete, das alle folgenden Prozessoren die Eigenschaften des 8086 zumindest als Untermenge besitzen mussten inklusive seiner Mängel wie dem berühmt-berüchtigten A20 Gate. Intel konnte die Architektur nie mehr reformieren.<\/p>\n

Meine Meinung zum 8086 hat sich durch das Schreiben meiner Hardwareartikel gebessert. In den Achtzigern empfand ich ihn als \u201eschrottig\u201c. Mein Liebling war der MC68000 \u2013 volle 16 MB unsegmentierter Adressraum, viele Register, intern 32 Bits lang, nur im Bus auf 24 Bits beschränkt. Der steckte im Macintosh, Sun Workstations. Nimmt man reale Benchmarks, so war der 8086 aber nur etwa 20 Prozent langsamer als ein 68000, den schlechten Ruf hatte er dadurch das nicht er im IBM PC steckte, sondern der 8088, der um 40 Prozent langsamer war und der wiederum nur mit 4,77 MHz getaktet, obwohl es den 8086 damals schon mit 8 MHz gab, was die Geschwindigkeit drastisch reduzierte.<\/p>\n

80186<\/h3>\n

Der 8086 war wie sein Vorgänger auf einen externen Taktgenerator angewiesen. So schob Intel wie beim 8080 ein verbessertes Modell nach. 1982 erschien der 80186, als Nachfolger des 8086. Er integrierte den Taktgenerator, aber auch andere Bausteine, die man häufig brauchte, wie Interruptcontroller, DMA-Steuerung, Zeitgeber und Refresherzeugung für DRAM. Der 80186 wurde relativ wenig eingesetzt. Zum einen, weil nicht alle diese Bausteine in einem PC benötigt wurden, dagegen eher bei einem Mikrocontroller nützlich waren. Zum Zweiten, weil wenige Monate später das noch leistungsfähigere Nachfolgemodell 80286<\/a> erschien, das Basis für die nächste Generation von PCs wurde. Der 80186 wurde aber noch lange als Embedded Prozessor von Intel produziert, erheblich länger als der 8086.<\/p>\n

80286<\/h3>\n

Mit dem 80286<\/a> wollte Intel nun zu Motorola aufschließen, wenn nicht überholen. Er musste aber kompatibel zum 8086 sein. Die Lösung war leider eine schlechte. Der 80286 hatte nun auch 16 MB Speicher, dazu gab es Mechanismen, mit denen er das Betriebssystem über Fehler informieren konnte. Beim Anlegen der Spannung tat er aber, als wäre er ein 8086. Die neuen Features bekam man erst zu sehen, wenn man mit einem Befehl in den neuen \u201eProtected Mode\u201c wechselte. Soweit so gut. Leider war das eine Einbahnstraße. Man konnte dann nicht mehr in den 8086-Modus, nun Real Modus genannt, wechseln. Intel dachte sich wohl \u201ewarum auch, hat man doch in dem Modus viel mehr Möglichkeiten\u201c. Sie vergaßen, dass Softwareentwickler ohne Betriebssystem das im Proteced Mode arbeitete, im Real Mode entwickelten. So war das Austesten von Programmen schwierig. Interessanterweise kümmerte das die meisten Benutzer des 80286, z.B. in einem IBM AT<\/a> nicht. Sie nutzten ihn einfach als schnellen 80286 unter DOS. Unter DOS wirkte sich vielmehr mit der Dauer aus, das auch der Arbeitsspeicher im Real Mode auf 1 MB beschränkt war, die PC aber in der zweiten Hälfte der Achtziger zunehmen mehr als 1 MB Speicher hatten. Ich denke das die Entwicklung von OS\/2<\/a> so lange dauerte, liegt mit daran. In jedem Falle ist bekannt das Bill Gates die Entwicklung von Windows nach Version 2 einstellen wollte, weil die Programmentwicklung für den 80286 so umständlich war. Nur durch Zufall entdeckte einer der Entwickler einen Debugger für den Protected Mode, der auch im Real Mode funktionierte und mit dem man nun endlich schneller vorwärts kam.<\/p>\n

Intel lernte daraus und implementierte im Nachfolgeprozessor 386<\/a> einen \u201evirtuellen\u201c 8086-Modus in dem der Prozessor beliebig viele 8086 Programm jedes in einem eigenen Adressraum ausführen konnte, was dann auch der Erfolg für Windows 3<\/a> war, denn so konnte es DOS-Programme ausführen, ohne bei deren Fehlern selbst abzustürzen.<\/p>\n

Pentium Pro<\/h3>\n

Der Pentium Pro<\/a> ist in dieser Rubrik ein Sonderfall. Er ist quasi das Gegenteil zum 8086\/80286. Während diese trotz Mängel in der Architektur erfolgreich waren, hat der Pentium Pro die Grundlagen für die noch heute geltende Architektur gelegt und war nicht erfolgreich.<\/p>\n

Intel hatte seit dem 8086 die Architektur immer mehr erweitert aber auch schneller gemacht. Der 486 konnte schon 80 Prozent der Befehle in einem Takt ausführen \u2013 der 8086 benötigte im Durchschnitt 10 Takte für einen Befehl. Der Pentium war als erster Prozessor superkalar<\/a>, das heißt er hatte mehr Funktionseinheiten als ein Befehl überhaupt beschäftigen kann. So konnte er im Idealfall zwei befehle gleichzeitig ausführen.<\/p>\n

Beim Pentium Pro zog man einen Schlussstrich um die x86 Architektur. Es gab zwei grundlegende Neuerungen. Die erste war das der Pentium keine x86 Befehle verarbeitete, sondern intern ein RISC Prozessor<\/a> war. Der Dekoder übersetzte die x86 Befehle zuerst in mehrere einfache Risc Befehle, \u201eMikroops\u201c genannt. Die wurden dann von dem Prozessor ausgeführt. Dabei konnte der Pentium Pro die Befehle umgruppieren und so vorziehen, um die Funktionseinheiten<\/a> voll auszulasten. Das nennt man \u201eOut of Order Execution\u201c und es macht einen Prozessor komplex, denn er muss Abhängigkeiten erkennen, Sprünge vorhersagen<\/a>, weil sonst die ganze Optimierung keinen Sinn macht. Aber es bringt einen enormen Geschwindigkeitsgewinn.<\/p>\n

Zum Verhängnis wurden dem Pentium Pro zwei Dinge. Der hausgemachte Fehler war, das man um die Performance zu steigern, den großen L2-Cache auf einem zweiten CPU-Die untergebracht hatte, anstatt (wie bisher) in separaten Chips auf dem Mainboard. Beide Dies mussten fehlerfrei sein und das senkte die Produktionsausbeuten ab und machte den Chip teuer. Zudem ließ der so mit vollem Prozessortakt angebundene Cache nicht eine so große Steigerung des Maximaltaktes wie bei den Vorgängern zu.<\/p>\n

Den zweiten Punkt hatte Microsoft zu verantworten. Der Pentium Pro erschien zusammen mit Windows 95, das von Microsoft als \u201e32 Bit Betriebssystem\u201c beworben wurde. Intel betrachtete den 8086 Code, den 16 Bit Code von DOS, als veraltetet und zum Aussterben verurteilt und der Prozessor konnte so die 32 Bit Befehle, die es ab dem 80386 gab, schnell ausführen, nicht aber die alten 16 Bit Befehle. In Benchmarks zeigte sich aber bald, dass unter Windows 95 der teure Pentium Pro langsamer als ein niedrig getakteter viel preiswerter Pentium war. Denn nur die Oberfläche, also das was der Anwender sieht, war in Windows 95 neu und 32 Bittig. Alles darunter, das eigentliche Betriebssystem war noch 16-bittiger Code.<\/p>\n

Der Pentium Pro wurde so erfolgreich in Servern und Workstations vermarktet, wo es echte 32 Bit Betriebssysteme gab. Mit ihm gab es auch erstmals einen Rechner mit Intel Prozessoren der die Top 500 Liste der schnellsten Computer anführte, aber im PC-Markt war er ein Flop. Intel lernte daraus, und trennte beim Nachfolger Pentium II<\/a> den Cache wieder vom Prozessor und baute beides zusammen auf ein CPU-Modul.<\/p>\n

Pentium 4<\/h3>\n

Den letzten Architekturwechsel machte Intel beim Pentium 4. Die beiden Nachfolger des Pentium Pro (Pentium II\/III) übernahmen seine Architektur, fügten weitere Funktionseinheiten zu, optimierten sie. Für die neue Netburst Architektur des Pentium 4 setzte Intel auf ein anderes Konzept. Anstatt vielen Funktioneinheiten gab es wenige. Dafür hatte der Prozessor eine extrem lange Pipeline, machte pro Takt also wenig, brauchte vergleichsweise viele Takte um einen Befehl zu dekodieren. Doch das machte nichts \u2013 es wurde pro Takt ja ein neuer Befehl in die Pipeline geschoben. Diese Pipeline<\/a> war auf hohe Taktfrequenz optimiert und in der Tat gelang es Intel den anfänglichen Takt innerhalb von zwei Jahren von 1,2 auf 3 GHz zu steigern. Nur \u2013 danach ging es nicht mehr weiter. In den nächsten zwei Jahren stieg er nur noch auf 3,83 GHz, mehr wurde nicht erreicht. Die Ursache waren Leckströme die bei jedem Takt entstehen. Je höher der Takt war, desto mehr Abwärme produziert der Prozessor, die Kühler wurden immer größer und als der Prozessor auf 1 cm\u00b2 Fläche 125 Watt abgab (eine Herdplatte gibt pro Flächeneinheit erheblich weniger Leistung ab) war die Grenze der Kühlsysteme erreicht. Zeitgleich hatte AMD den Athlon auf dem Markt, mit einer Architektur die sich mehr am Pentium Pro orientierte \u2013 mehr Funktionseinheiten aber niedriger Takt und die Athlons waren schneller als der Pentium 4<\/a>.<\/p>\n

Intel zog die Reisleine und lies eine neue Architektur designen, nun auf geringe Verlustleistung getrimmt. Basis war der Pentium M, ein Mobilprozesor für Laptops den das israelische Designbüro von Intel entwickelt hatte und der wiederum auf dem Pentium Pro Design basierte. Die neue Architektur hieß \u201eCore Mikroarchitektur<\/a>\u201c, hatte erheblich niedrigen Takt von maximal 2 GHz, war durch mehr Parallelität trotzdem schneller. Damit überholte Intel wieder AMD, die nach einigen Jahren ihren Athlon auch kaum noch in der Leistung steigern konnte. Die Architektur ist bis heute aktuell und wurde seitdem vor allem erweitert.<\/p>\n","protected":false},"excerpt":{"rendered":"

<\/div>\n

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

<\/div>\n

Nach Intels Flops die ich gestern vorgestellt habe, heute ein weiterer Beitrag zu dem Thema. Diesmal geht es um Prozessoren \/ Architekturen bei denen die Geschichte anders lief, als von Intel geplant, auch wenn man in den meisten Fällen nicht von einem kommerziellen Fehlschlag sprechen kann.<\/p>\n","protected":false},"author":169,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[4],"tags":[4828,4594,3695,192,3698,4829],"class_list":["post-15814","post","type-post","status-publish","format-standard","hentry","category-computer","tag-4828","tag-4594","tag-3695","tag-intel","tag-pentium-4","tag-pentium-pro","entry"],"a3_pvc":{"activated":true,"total_views":8282,"today_views":0},"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":18610,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/03\/27\/galileos-cds-teil-1\/","url_meta":{"origin":15814,"position":0},"title":"Galileos CDS – Teil 1","author":"Bernd Leitenberger","date":"27. M\u00e4rz 2026","format":false,"excerpt":"Hall\u00f6chen, es wird Zeit das ich mich mal wieder melde. Es gab zwei Gr\u00fcnde, warum ich mich so rar gemacht habe. Das eine ist das es gerade nicht so viel aktuelles gibt, au\u00dfer einem Update zu Artemis, zu dem ich vielleicht noch etwas schreibe. W\u00e4hrend Trump das ganze Programm nach\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg07.met.vgwort.de\/na\/4fb81c7bafbd4d9d88b5695abdb33d29","width":350,"height":200},"classes":[]},{"id":18612,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/03\/28\/galileos-cds-teil-2\/","url_meta":{"origin":15814,"position":1},"title":"Galileos CDS \u2013 Teil 2","author":"Bernd Leitenberger","date":"28. M\u00e4rz 2026","format":false,"excerpt":"So, heute geht es weiter mit Teil 2 \u00fcber Galileos CDS, dieser Beitrag schlie\u00dft nahtlos an den ersten Beitrag von gestern an, wie man schon an der ersten Textzeile sieht. Nach der Einleitung im ersten Teil geht es heute weiter damit warum der RCA 1802 genutzt wurde und was seine\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg07.met.vgwort.de\/na\/191e4b0728de42829cf656027b84dc82","width":350,"height":200},"classes":[]},{"id":18614,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/03\/29\/galileos-cds-teil-3\/","url_meta":{"origin":15814,"position":2},"title":"Galileos CDS – Teil 3","author":"Bernd Leitenberger","date":"29. M\u00e4rz 2026","format":false,"excerpt":"So nun zum dritten Teil \u00fcber das prim\u00e4re Computersystem von Galileo, das CDS. Nachdem sich die ersten beiden Teile nur mit dem RCA 1802, warum er gew\u00e4hlt wurde und seiner Architektur befassten geht es heute um das Computersystem selbst. Der Artikel schlie\u00dft so an seine beiden Vorg\u00e4nger gestern und vorgestern\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg07.met.vgwort.de\/na\/6e7f572a246b4ac395de9c260733b707","width":350,"height":200},"classes":[]},{"id":18511,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/01\/27\/musks-ki-rechenzentren-im-orbit\/","url_meta":{"origin":15814,"position":3},"title":"Musks KI-Rechenzentren im Orbit","author":"Bernd Leitenberger","date":"27. Januar 2026","format":false,"excerpt":"Bei meinem regelm\u00e4\u00dfigen Besuch des Space Reviews stie\u00df ich auf diesen Artikel: SpaceX, orbital data centers, and the journey to Mars. Ich hatte in meiner Nachlese schon erw\u00e4hnt das Elon Musk, nachdem er dies lange verschoben hat nun plant SpaceX an die B\u00f6rse zu bringen. Ich meinte aber, das l\u00e4ge\u2026","rel":"","context":"In "SpaceX"","block_context":{"text":"SpaceX","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/spacex\/"},"img":{"alt_text":"","src":"https:\/\/vg06.met.vgwort.de\/na\/0ee72da693054bc3b5c3f00214a7e2b3","width":350,"height":200},"classes":[]},{"id":18524,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2026\/02\/06\/elon-musks-ki-rechenzentren-im-orbit-nochmals-nachgerechnet\/","url_meta":{"origin":15814,"position":4},"title":"Elon Musks KI-Rechenzentren im Orbit – nochmals nachgerechnet","author":"Bernd Leitenberger","date":"6. Februar 2026","format":false,"excerpt":"Ich habe mich ja schon mal mit diesem Thema besch\u00e4ftigt, in dem es vor allem um die Kosten und den wirtschaftlichen Unsinn ging - warum sollte ich ein Rechenzentrum in den Orbit bringen, wenn ich es billiger auf der Erde bauen kann und es auch gen\u00fcgend Gegenden gibt in denen\u2026","rel":"","context":"In "Raumfahrt"","block_context":{"text":"Raumfahrt","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/"},"img":{"alt_text":"","src":"https:\/\/vg06.met.vgwort.de\/na\/78014052fde04012a2be60bd108cd4bb","width":350,"height":200},"classes":[]},{"id":18439,"url":"https:\/\/www.bernd-leitenberger.de\/blog\/2025\/10\/14\/nachlese-elfter-teststart-des-starships-ift-11\/","url_meta":{"origin":15814,"position":5},"title":"Nachlese elfter Teststart des Starships IFT-11","author":"Bernd Leitenberger","date":"14. Oktober 2025","format":false,"excerpt":"Die Nachlese zum gestrigen Starship-Start kann ich recht kurz machen, denn diesmal klappte noch mehr als beim letzten Mal. Dauerhaft, zusammen mit dem Artikel f\u00fcr den Flugplan und Abbildungen findet ihr das ganze auch auf der Website. Drei Dinge fielen mir auf: Beim Boostback-Burn der Super Heavy schaltete eines der\u2026","rel":"","context":"In "SpaceX"","block_context":{"text":"SpaceX","link":"https:\/\/www.bernd-leitenberger.de\/blog\/category\/raumfahrt\/spacex\/"},"img":{"alt_text":"","src":"https:\/\/vg04.met.vgwort.de\/na\/d237e8ebe33746ddb174f7e072b94b6c","width":350,"height":200},"classes":[]}],"jetpack_sharing_enabled":true,"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/posts\/15814","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/users\/169"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/comments?post=15814"}],"version-history":[{"count":0,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/posts\/15814\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/media?parent=15814"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/categories?post=15814"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bernd-leitenberger.de\/blog\/wp-json\/wp\/v2\/tags?post=15814"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}