Le détective matériel Ken Shirriff s’est rendu sur son blog pour explorer l’ensemble des fonctionnalités et les opérations possibles que l’on pourrait tirer du plus ancien processeur x86 du monde – l’Intel 8086. En suivant les opérations du microcode du 8086, Shirriff a trouvé des « choix » de conception inattendus : à partir du microcode propriétaire destiné à piéger les voleurs IP par des décisions de conception douteuses (mais nécessaires) qui permettaient aux processeurs 8086 d’exécuter des instructions inconnues (avec des résultats tout aussi peu connus), le travail de détective met en lumière ce qui est probablement la version de processeur la plus importante des cinquante dernières ou donc des années.
La première implémentation au monde du jeu d’instructions x86 sur le 8086 d’Intel correspondait à peu près à ce que vous attendiez d’un processeur sorti à la fin des années soixante-dix. Alors que les puces de pointe d’aujourd’hui peuvent transporter des centaines de milliards de transistors (les blocs de construction de base pour des circuits plus complexes), le premier processeur x86 commercial d’Intel, l’Intel 8086 5-10 MHz, devait se contenter de seulement 29 000 d’entre eux.
Les processeurs modernes vous empêchent d’exécuter des instructions inexistantes. Mais les premiers microprocesseurs comme l’Intel 8086 (1978) ne vérifiaient pas les instructions illégales. En exécuter un pourrait fournir des fonctionnalités cachées ou même donner accès à des registres cachés auxquels vous ne pourriez pas accéder autrement.🧵 pic.twitter.com/BCdp7ZBY6V16 juillet 2023
Plus de transistors équivaut généralement à plus de performances et surtout à plus de fonctionnalités (une prise en charge accrue d’instructions plus variées et complexes et une accélération basée sur le matériel sont l’affiche ici). À l’époque, comme aujourd’hui, un équilibre entre les performances, l’efficacité énergétique et le nombre de transistors/zone de matrice imposait des limitations strictes sur la façon dont les allocations de transistors étaient gérées – et finalement, quelles fonctionnalités étaient jugées « nécessaires » et « jetables ».
Selon la découverte de Shirriff, une particularité particulière du 8086 d’Intel est que le processeur ne possédait aucun frein et contrepoids pour exécuter le microcode – la couche la plus proche du métal entre le logiciel et le matériel qui est responsable de la division des instructions complexes en une série de plus simples, pas à pas, que le CPU peut exécuter. Mais avec des transistors limités à 29 000, Intel a choisi de ne pas inclure de verrouillage au niveau matériel sur les instructions pouvant et ne pouvant pas être exécutées. Habituellement, les instructions fonctionnent sur la base d’une liste blanche – le processeur permet l’exécution de microcodes dont il sait déjà qu’ils peuvent être traités dans sa conception matérielle.
Mais comme le 8086 d’Intel était si restreint pour l’espace des transistors, la société n’a en fait pas intégré la liste blanche des opérations de microcode que le processeur pouvait traiter, ce qui signifie qu’en présence d’opérations de microcode « illégales » (lire : non prises en charge), le 8086 d’Intel a fait de son mieux pour résoudre l’opération de microcode de toute façon – sans spécifier le résultat de l’opération « demandée illégalement ».
Au total, l’Intel 8086 supportait 521 instructions, contenues dans sa puce ROM Microcode (Read-Only Memory). Certaines de ces 512 instructions étaient des doublons (en tant que mécanismes de secours et autres raisons), mais d’autres n’ont jamais été rendues publiques : certaines opérations de microcode n’ont pas été documentées – que ce soit pour des fonctionnalités prévues qui n’ont jamais été implémentées ou pour d’autres raisons.
Pourtant, un microcode intéressant, tel que vérifié par Shirriff, a aidé Intel à défendre sa propriété intellectuelle contre les voleurs potentiels. En remplissant une liste d’instructions à partir des 512 disponibles dans la ROM du 8086, Shirring a pu discerner les opcodes avec des fonctions connues (en blanc); ceux en orange, jaune et vert ont été laissés vides pour le 8086, mais ont été remplis sur les prochains processeurs d’Intel, les 80186, 80286 et 80386 respectivement ; et enfin, la valeur aberrante violette : un opcode qui a été implémenté dans les processeurs Intel 8086 et suivants, mais qui n’a jamais été ouvertement documenté.
Le point de vue de Shirriff sur le drapeau violet sans papiers – qui n’a été mis en lumière dans les documents d’Intel qu’en 2017, bien qu’il vive dans la conception x86 de l’entreprise depuis le 8086 – est qu’il a servi de sorte de pot de miel pour quiconque cherche à copier la technologie d’Intel. Si une entreprise avait pris des raccourcis dans le développement de ses propres solutions de processeur et avait à la place volé l’IP du microcode d’Intel, alors ses processeurs effectueraient la même opération SALC (Set AL to Carry) lorsqu’ils alimentaient les bits de code machine pertinents – cela équivaut à une identification par code-barres cela permettrait à Intel de poursuivre plus efficacement tous les voleurs d’IP.
Malheureusement, le microcode « copyright trap » n’a pas beaucoup servi Intel, pas même dans les premiers jours du 8086 lorsque la concurrence était plus variée : Intel espérait que son instruction SALC avait été implémentée dans la propre (et meilleure) prise de NEC. Les processeurs x86 d’Intel sous la forme des processeurs NEC V20 et NEC V30. Mais ce n’était pas le cas : une décision fédérale de 1989 affirmait que NEC n’avait pas enfreint le droit d’auteur d’Intel (et l’instruction SALC n’était donc pas là). Mais d’autres choses se produisent lorsqu’une poursuite pour violation du droit d’auteur est lancée, des choses qui n’ont pas grand-chose à voir avec les mérites du droit d’auteur lui-même. La décision d’Intel de poursuivre et de bloquer NEC et la vente de ses processeurs V20 et V30 est en partie la raison pour laquelle il n’y a pas plus d’acteurs sur la scène compétitive de la conception de puces x86.