Der Hardware-Detektiv Ken Shirriff hat sich auf seinem Blog umgesehen um den Funktionsumfang und die möglichen Operationen zu untersuchen, die man aus der ältesten x86-CPU der Welt – dem Intel 8086 – herausholen könnte. Indem Shirriff die Mikrocode-Operationen des 8086 verfolgte, fand er einige unerwartete Design-„Entscheidungen“: Von proprietärem Mikrocode, der IP-Diebe in die Falle locken sollte, bis hin zu fragwürdigen (aber notwendigen) Designentscheidungen, die es 8086-Prozessoren ermöglichten, unbekannte Anweisungen auszuführen (mit ebenso wenig bekannten Ergebnissen), wirft die Detektivarbeit etwas Licht auf die wahrscheinlich wichtigste CPU-Version der letzten etwa fünfzig Jahre.
Die weltweit erste Implementierung des x86-Befehlssatzes auf Intels 8086 entsprach in etwa dem, was man von einer CPU aus den späten Siebzigern erwarten würde. Während die heutigen Spitzenchips Hunderte Milliarden Transistoren (die Grundbausteine für komplexere Schaltkreise) tragen können, musste sich Intels erste kommerzielle x86-CPU, der 5-10 MHz Intel 8086, mit lediglich 29.000 Transistoren begnügen.
Moderne Prozessoren verhindern die Ausführung nicht vorhandener Anweisungen. Aber frühe Mikroprozessoren wie der Intel 8086 (1978) prüften nicht auf illegale Anweisungen. Wenn Sie eines ausführen, könnten versteckte Funktionen bereitgestellt oder sogar Zugriff auf versteckte Register gewährt werden, auf die Sie sonst keinen Zugriff hätten.🧵 pic.twitter.com/BCdp7ZBY6V16. Juli 2023
Mehr Transistoren bedeuten im Allgemeinen mehr Leistung und insbesondere mehr Funktionalität (verstärkte Unterstützung für vielfältigere und komplexere Anweisungen und hardwarebasierte Beschleunigung sind hier das Aushängeschild). Damals wie heute erzwang ein Gleichgewicht zwischen Leistung, Energieeffizienz und Transistoranzahl/Chipfläche strenge Einschränkungen bei der Handhabung der Transistorzuweisungen – und letztendlich bei den Funktionen, die als „notwendig“ und „einmal wegwerfbar“ galten.
Laut Shirriffs Erkenntnissen besteht eine besondere Eigenart von Intels 8086 darin, dass die CPU über keine Checks and Balances für die Ausführung von Mikrocode verfügte – der schichtnahen Schicht zwischen Software und Hardware, die für die Aufteilung komplexer Anweisungen in eine Reihe von Befehlen verantwortlich ist einfachere, schrittweise Anleitungen, die die CPU ausführen kann. Da die Anzahl der Transistoren jedoch auf 29.000 begrenzt war, entschied sich Intel dafür, keine Sperre auf Hardwareebene einzubauen, die festlegt, welche Anweisungen ausgeführt werden dürfen und welche nicht. Normalerweise funktionieren Anweisungen auf Whitelist-Basis – die CPU ermöglicht die Ausführung von Mikrocodes, von denen sie bereits weiß, dass sie in ihrem Hardware-Design verarbeitet werden können.
Aber da Intels 8086 so wenig Platz für Transistoren hatte, hat das Unternehmen tatsächlich nicht die Mikrocode-Operations-Whitelist eingebaut, die die CPU verarbeiten konnte, was bedeutet, dass bei Vorhandensein von „illegalen“ (sprich: nicht unterstützten) Mikrocode-Operationen Intels 8086 versuchte trotzdem sein Bestes, um den Mikrocode-Vorgang aufzulösen – ohne das Ergebnis des „illegal angeforderten“ Vorgangs anzugeben.
Insgesamt unterstützte der Intel 8086 521 Anweisungen, die in seinem Microcode-ROM-Chip (Read-Only Memory) gespeichert waren. Einige dieser 512 Anweisungen waren Duplikate (als Fallback-Mechanismen und aus anderen Gründen), andere wurden jedoch nie veröffentlicht: Bestimmte Mikrocode-Operationen blieben undokumentiert – sei es für geplante Funktionen, die nie implementiert wurden, oder aus anderen Gründen.
Doch ein interessanter Mikrocode, der von Shirriff bestätigt wurde, half Intel dabei, sein geistiges Eigentum vor potenziellen IP-Dieben zu schützen. Indem er eine Befehlsliste aus den verfügbaren 512 im ROM des 8086 ausfüllte, konnte Shirring die Opcodes mit bekannten Funktionen (in Weiß) erkennen; die in Orange, Gelb und Grün blieben beim 8086 leer, wurden aber bei Intels nächsten Prozessoren, dem 80186, 80286 bzw. 80386, bestückt; und schließlich der violette Ausreißer: ein Opcode, der in Intels 8086 und nachfolgenden Prozessoren implementiert wurde, der jedoch nie offen dokumentiert wurde.
Shirriffs Sicht auf die undokumentierte lila Flagge – die erst 2017 in den Dokumenten von Intel ans Licht kam, obwohl sie seit dem 8086 im x86-Design des Unternehmens lebte – ist, dass sie als eine Art Honigtopf für jeden diente, der Intels Technologie kopieren wollte. Wenn ein Unternehmen bei der Entwicklung seiner eigenen CPU-Lösungen Abstriche gemacht und stattdessen Intels Mikrocode-IP gestohlen hätte, würden seine CPUs die gleiche SALC-Operation (Set AL to Carry) ausführen, wenn sie mit den relevanten Maschinencodebits versorgt würden – das entspricht einer Barcode-Identifizierung Dies würde es Intel ermöglichen, IP-Diebstähle effektiver zu verfolgen.
Leider nützte der „Copyright-Falle“-Mikrocode Intel nicht viel, nicht einmal in den frühen Tagen des 8086, als die Konkurrenz vielfältiger war: Intel hoffte, dass seine SALC-Anweisung in NECs eigener (und besserer) Version implementiert worden war Intels x86-Prozessoren in Form der NEC V20- und NEC V30-Prozessoren. Dies war jedoch nicht der Fall: In einem Bundesurteil aus dem Jahr 1989 wurde festgestellt, dass NEC das Urheberrecht von Intel nicht verletzt hatte (und die SALC-Anweisung daher nicht vorhanden war). Aber wenn eine Klage wegen Urheberrechtsverletzung erhoben wird, passieren noch andere Dinge, die wenig mit der Berechtigung des Urheberrechts selbst zu tun haben. Die Entscheidung von Intel, NEC und den Verkauf seiner V20- und V30-Prozessoren zu verklagen und zu blockieren, ist einer der Gründe dafür, dass es in der hart umkämpften Szene des x86-Chipdesigns nicht mehr Akteure gibt.