En quoi consiste exactement le microcode et en quoi diffère-t-il du micrologiciel?
En ce qui concerne la terminologie, qu'est-ce que "microcode" et s'il peut être mis à jour, en quoi diffère-t-il du firmware?
Cette question n'est pas un duplicata de cette question (pour autant que je sache) que j'ai également posée à propos de la modification du microcode. Ici, je veux strictement savoir comment utiliser ces termes correctement.
Mettre à jour
J'ai choisi une réponse, mais je n'en suis pas particulièrement satisfaite. J'ai retenu beaucoup de réponses et je trouve que beaucoup d'entre elles sont également insatisfaisantes. Alors laisse-moi te présenter mes deux cadres,
- "Le microcode du processeur s'apparente à un microprogramme de processeur." Alors que je lis cela de plus en plus, c'est comme ça que je le prends. "Microcode" est dans ce contexte juste un marketing sur "microprogramme de processeur". Ours avec moi, ..
- Ou alors je me trompe et je sais que cela arrive! Dans ce cas, j'ai besoin d'une idée beaucoup plus approfondie de la raison pour laquelle je me trompe. Dans les réponses que j’ai lues pour indiquer que j’ai tort, j’ai du mal à les comprendre,
- "Exécution contre données" beaucoup de réponses utilisent ce paradigme, mais pour le CPU, cela n'a pas beaucoup de sens pour moi. Certains micrologiciels d’affirmation sont exécutés, mais par quoi? S'agissant de la CPU, les programmes sont-ils des instructions ou des données?
- Si le micrologiciel relie le logiciel et le matériel (lisez: le truc électrotechnique des Dieux), comment se fait-il que le microcode ne satisfasse pas également cette distinction.
- "Interpréter" au fil du temps, cela fait de moins en moins de sens. Qu'est-ce que cela signifie de dire "les instructions matérielles sont interprétées" avec Microcode. Si cela était vrai, est-ce que quelque chose serait aussi performant s'il n'était pas interprété mais précompilé avec des instructions matérielles différentes et simplement "exécuté"? De plus, comment General MIDI n'est-il pas interprété de la même manière? C'est un langage qui est interprété par "microcode MIDI" et fonctionne sur le matériel. Ou encore, des terminaux stupides qui interprètent les instructions du téléimprimeur pour l'affichage visuel?
- Le "microcode" s’applique-t-il au code qui s’exécute sur les cartes son et les cartes graphiques (GPU) ?
Le micrologiciel Origin of the Word se situe à mi-chemin entre le matériel et le logiciel - un logiciel intégré au matériel. Il s'agit d'un logiciel stocké dans une mémoire non volatile sur un périphérique matériel. Des exemples sont la mémoire EEPROM et la mémoire flash intégrée à des périphériques matériels, lorsqu'elles sont utilisées pour stocker du code exécuté par le périphérique lui-même.
Il est de plus en plus courant dans certains types de matériel que son "micrologiciel" soit stocké dans le logiciel du pilote et chargé sur le périphérique lors de son démarrage/initialisation, au lieu de le laisser en permanence sur le périphérique. Par exemple, de nos jours, par exemple, stocker quelques centaines de Ko de code de microprogramme dans un pilote de logiciel chargé sur le système d'exploitation hôte et l'envoyer au périphérique initialisé par le pilote.
Ceci est souvent encore appelé "firmware" même si, en fonction de la définition du firmware que vous acceptez, vous ne pouvez pas, techniquement, le considérer comme un firmware car il ne réside pas sur le matériel (si vous détachez le matériel et le placez sur un autre ne conservera pas cette version du "firmware").
Le microcode est un sous-ensemble de ce dernier type de "firmware". Microcode n'est pas un terme générique pour tous les "micrologiciels" chargés sur un périphérique au démarrage. Au lieu de cela, il est spécifique aux processeurs, où le microcode constitue essentiellement la couche de traduction entre les instructions de processeur standard de niveau supérieur et les opérations de niveau inférieur spécifiques à ce processeur. Il est chargé au démarrage par le BIOS sur le processeur, mais peut également être remplacé ultérieurement par l’OS.
Une mise à jour vers le microcode peut permettre de modifier le comportement de bas niveau d'un processeur pour contourner certains bogues à découvrir, sans avoir à remplacer le matériel du processeur. Microcode contient généralement le mappage le plus efficace possible d'instructions de niveau supérieur à inférieur pour une vitesse et une efficacité énergétique optimales. Ainsi, lorsqu'un changement de microcode est nécessaire pour corriger un bogue, il peut en résulter des performances réduites.
Notez que Meltdown (la vulnérabilité affectant uniquement les puces Intel) ne peut pas être corrigé uniquement avec les mises à jour du microcode et nécessite des modifications des fonctionnalités du système d'exploitation principal, ce qui peut réduire davantage les performances. Spectre (la vulnérabilité des puces Intel, AMD et ARM) peut éventuellement être corrigé par les mises à jour du microcode.
Pour répondre à certaines de vos questions spécifiques depuis votre modification:
Oui, le microcode est essentiellement un microprogramme qui s'exécute sur le processeur. Le terme spécial "microcode" désigne spécifiquement le microprogramme d’un processeur contenant le plan de conversion du langage machine standard en instructions de processeur de bas niveau. C'est donc un terme plus spécifique que firmware.
Notez que, comme indiqué ci-dessus, il n’est pas stocké sur le processeur tant qu’il est éteint, mais chargé dessus à chaque démarrage, il ne fonctionne donc pas comme un firmware traditionnel. Cependant, beaucoup de matériel le fait maintenant et s'appelle toujours "firmware". L'appeler firmware est donc acceptable.
Je ne pense pas que tu aies tort. Le micrologiciel n'a pas besoin d'être écrit dans un certain langage machine et son exécution ne doit pas être déclenchée d'une certaine manière. À un certain niveau bas, tout le code machine est une "donnée" qui est "lue" par un processeur et interprétée d'une certaine manière.
Le terme "microcode" est généralement utilisé uniquement pour les unités centrales principales et non pour les cartes graphiques ou autres matériels, même si le code de ces autres périphériques peut être chargé de la même manière.
https://wiki.debian.org/Microcode
CPU Microcode
Le microcode du processeur s'apparente au microprogramme du processeur. Le noyau peut mettre à jour le microprogramme du processeur sans avoir à le mettre à jour via une mise à jour du BIOS. Une mise à jour du microcode est conservée dans la mémoire volatile, ainsi le BIOS/UEFI ou le noyau met à jour le microcode à chaque démarrage.
Les processeurs d'Intel et d'AMD peuvent nécessiter des mises à jour de leur microcode pour fonctionner correctement. Ces mises à jour corrigent des bugs/errata pouvant entraîner des problèmes de traitement, de corruption du code et des données, ainsi que du blocage du système.
Le BIOS (ou UEFI) met à jour le microcode de la CPU lors du démarrage. Toutefois, le fabricant de la carte mère ne publie généralement pas de mises à jour fréquentes du BIOS/UEFI, ou l'utilisateur n'installe pas ces mises à jour. Pour ces raisons, le processeur système est susceptible de fonctionner avec un microcode obsolète sur un grand nombre de systèmes.
Exemples:
https://www.win-raid.com/t3355f47-Intel-AMD-amp-VIA-CPU-Microcode-Repositories.html
Eh bien, les "mises à jour de microcode" d'Intel sont en fait des "mises à jour de" microprogrammes "en ce sens qu'elles mettent à jour beaucoup plus que la simple unité de traduction du microcode du processeur.
Ces mises à jour de package de processeur unifié que nous appelons «mises à jour de microcode» pour Intel mettent également à jour d'autres microcontrôleurs intégrés (tels que le PMU et le cœur de la gestion de l'alimentation), ainsi que plusieurs tableaux de paramètres pour différents sous-systèmes de processeur intégrés. Ils sont plutôt complexes.
Ces informations sont disponibles sur plusieurs brevets d'Intel liés aux mises à jour de microcode et de microcode.
Je pense que le terme "microcode" désigne principalement ce que fait le code (il exécute des instructions de bas niveau en utilisant des instructions même de bas niveau), tandis que le terme "firmware" se réfère principalement à la manière dont il est stocké et géré (moins facilement mis à jour que le logiciel). , plus facilement mis à jour que le matériel). En ce sens, cela ressemble plutôt à la distinction entre une "application" et un "fichier JAR" - le même programme peut être les deux, mais vous le regardez sous deux perspectives différentes.
Incidemment, l’idée du microcode remonte à Maurice Wilkes en 1951, des décennies avant l’installation de processeurs informatiques dans du silicium.
"Microcode" était le terme d'origine et faisait référence aux instructions utilisées pour implémenter un interpréteur du jeu d'instructions "public" du processeur.
Mais avec le temps, avec de nombreuses variations dans les schémas de mise en œuvre, la distinction, telle qu'elle était, devenait plus vague. Il y avait d’abord le microcode horizontal par rapport au vertical, puis divers schémas pour l’écriture de "microcode" (pour implémenter, par exemple, les instructions d’entrée/sortie) dans le jeu d’instructions de processeur "principal". Il fallait ensuite faire la distinction entre le code qui était facilement chargé via des opérations "d'exécution" de programme ordinaires et le code (pour le BIOS, par exemple) qui était enregistré dans ROM ou dans un autre stockage protégé et relativement immuable. Ainsi, le terme "firmware" a été inventé pour se référer à ces instructions qui étaient en quelque sorte rendues plus persistantes (et moins accessibles pour une modification par l'utilisateur) stockées.
Mais les choses se sont transformées et tordues plusieurs fois depuis que ces premières distinctions ont été faites, et les termes ne peuvent plus être définis avec précision dans un environnement de processeur et de système d'exploitation donné.
[NB: cette réponse est spécifiquement destinée à traiter le montage récent et n’ajoute rien aux nombreuses réponses sonores déjà postées.]
Donc, pour réitérer: microcode (au moins en première approximation) est un type spécifique de microprogramme.
"Microcode" est dans ce contexte juste un marketing sur "microprogramme de processeur".
Eh bien, ce n'est pas du marketing. Le marketing l'aurait appelé XBoost Pro (TM) ou quelque chose du genre. C'est plutôt un terme d'ingénierie; si vous concevez des CPU, la distinction entre le microcode et les autres microprogrammes de la CPU (et le type de microprogrammes typique des autres périphériques) est importante pour vous. Si non, ce n'est probablement pas.
Si vous concevez des cartes mères ou écrivez des systèmes d'exploitation, vous utiliserez probablement «mise à jour du microcode» pour désigner la «mise à jour du microprogramme du processeur», moins encombrante et moins familière. La plupart des mises à jour de microprogrammes de processeur affectent principalement le microcode, il est donc assez proche de la même chose. Vous connaissez probablement la différence, mais vous n'avez pas besoin de vous en soucier.
L'utilisateur final n'a pas besoin de connaître ni de se soucier de la différence et, dans un monde idéal, il n'entendra jamais le mot "microcode".
Je suppose que cela a attiré votre attention dans la couverture par la presse des vulnérabilités d'exécution spéculatives récentes, même si vous en avez peut-être déjà entendu parler plus tôt, dans un contexte qui rend plus évident le fait que vous ne devez pas vous en soucier. Ces vulnérabilités ont été publiées plus tôt que prévu, ce qui a peut-être eu pour résultat une couverture de presse moins soignée qu’elle ne l’aurait été autrement. Du point de vue de l'utilisateur final, vous devez installer les mises à jour du BIOS, les mises à jour du système d'exploitation et, dans certains cas, les mises à jour des applications. vous n'avez besoin ni de savoir ni de soins qui, le cas échéant, incluent un nouveau microcode.
Ainsi, même en réalisant que vous n'avez probablement pas besoin de savoir ou de vous inquiéter, vous pouvez toujours être intéressé par pure curiosité: comment pourriez-vous distinguer le microcode des autres microprogrammes?
Eh bien, la première chose à reconnaître est qu’il n’existe pas nécessairement une définition unique et définitive, c’est plutôt une situation/ une situation de Bleggs et Rubes . Néanmoins, il y a certaines choses que nous pouvons dire à propos du microcode:
Le microcode fonctionne généralement à l'intérieur d'un processeur plutôt que sur un processeur. C'est la vue de haut niveau.
L'architecture du microcode est généralement très différente de l'architecture du code ordinaire, y compris du micrologiciel ordinaire. Il est susceptible d'être très parallèle et d'être implémenté beaucoup plus près du matériel. Plusieurs des réponses existantes (y compris votre propre réponse) en discutent, bien que les détails puissent varier en fonction de la conception de la CPU.
Bien que le matériel soit souvent conçu pour exécuter uniquement le micrologiciel fourni par le fabricant, il est pas particulièrement rare que le micrologiciel tiers soit utilisé - même si cela annulera probablement la garantie! Le microcode tiers est beaucoup plus rare, bien que je pense que dans les temps anciens (lorsqu'un processeur avait la taille d'une boîte à pain), certains utilisateurs finaux modifiaient le microcode dans leurs processeurs. Autant que je sache, cela n’est pas possible dans le type de CPU utilisé dans les PC.
Microcode traduit ou aide généralement à mettre en œuvre une architecture de jeu d’instructions publique, c’est-à-dire qu’il exécute le code machine utilisé par le concepteur du système d’exploitation et les programmeurs d’applications. Plus à ce sujet dans la section suivante.
"Exécution vs données" beaucoup de réponses utilisent ce paradigme
Je crains bien, mais de façon très confuse, mais je vais répondre à mon propre commentaire. Cette section sert également à développer le dernier point ci-dessus. Le but ici est d’essayer de faire la distinction entre le travail effectué par la CPU (obtenu par une combinaison de matériel et de microcode) et le travail effectué par un périphérique type (réalisé par une combinaison de matériel et de microprogrammes). Je vais choisir un disque dur SATA.
Le lecteur SATA suit les instructions de l'ordinateur, qui suivent les instructions "lire les données du secteur 5 123" et "écrire ces données dans le secteur 1 321". Le micrologiciel du lecteur est responsable de la mise en place du matériel, et il s’agit généralement d’un code assez ordinaire fonctionnant sur un processeur intégré. Les instructions du lecteur arrivent de manière séquentielle, même si elles peuvent ne pas être traitées dans l'ordre dans lequel elles arrivent. Ces instructions ne sont pas un programme, elles sont envoyées par un programme exécuté sur la CPU principale. En particulier, il n’existe aucun flux de contrôle, c’est-à-dire aucune instruction pour indiquer au lecteur SATA les instructions à exécuter par la suite.
Le processeur est en charge de l'ordinateur. Une fois l’initialisation terminée, il exécute les instructions ("code machine") fournies par la carte mère (le BIOS, un autre type de microprogramme) lui ordonnant d’exécuter le code machine fourni par le système d’exploitation, qui lui ordonne d’exécuter le code machine fourni. par les fournisseurs d'applications. La CPU récupère elle-même le code machine de l'EEPROM (dans le cas du BIOS) ou RAM (dans le cas du système d'exploitation et des applications). En particulier, le code machine a un flux de contrôle: le code machine indique à la CPU quel code machine exécuter ensuite. Vous pouvez parcourir le même code machine à plusieurs reprises, vous pouvez exécuter différents bits de code en fonction des données sur lesquelles le code fonctionne. Les instructions dans une langue d'interface de périphérique, comme le code SATA, permettent d'effectuer un ensemble limité de tâches simples, mais le code machine peut faire rien. (Voir aussi Complétude de Turing .)
Nous pourrions réécrire le point final ci-dessus comme suit: le microcode implémente généralement un langage Turing Complete; les micrologiciels ordinaires ne le font généralement pas.
Que veut dire "les instructions matérielles sont interprétées" avec le microcode.
Vrai mais probablement déroutant; le point important est la distinction entre le code machine, qui a un flux de contrôle et Turing Complete, et les instructions définies par une interface de périphérique telle que SATA, ce qui n’est pas et n’est pas.
Le "microcode" s'applique-t-il au code qui s'exécute sur les cartes son?
Non, les cartes son reçoivent des instructions et non du code, tout comme les disques SATA. Les instructions peuvent ressembler à "jouer un dièse" ou "interpréter ces données comme une forme d'onde et les lire". Toujours très simple.
et cartes vidéo (GPU)?
Les anciennes cartes vidéo (sans GPU) sont identiques aux disques SATA. Les instructions sont comme "définir ce pixel sur cette couleur" ou "écrire un A à cette position".
Les GPU sont compliqués et se situent quelque part entre les deux mondes que j'ai tenté de décrire ci-dessus. Il est probablement plus simple de les considérer comme un ordinateur spécialisé installé à l'intérieur de l'ordinateur principal, qui possède ses propres processeurs. Il est vrai que les périphériques tels que les lecteurs SATA ont également des processeurs intégrés, mais la différence est que le processeur intégré dans un lecteur SATA exécute uniquement le code fourni par le fabricant du lecteur, alors que les GPU exécutent également le code fourni par le système d'exploitation et/ou le fournisseur de l'application. Vraiment c'est une toute une question séparée.
TL; DR: le microcode est un type de microprogramme spécifique, qui aide le matériel à implémenter un jeu d’instructions Turing Complete.
Le micrologiciel fait généralement référence au code des périphériques contenant un processeur et non le processeur lui-même, par exemple. le firmware pour un téléphone Android.
Le microcode est une couche de traduction entre des jeux d'instructions complexes (par exemple, 486, 686, etc.) et les instructions de niveau inférieur pour lesquelles les fabricants de puces conçoivent du silicium. Ainsi, un certain nombre d'instructions du jeu d'instructions de la CPU ne sont pas implémentées dans le silicium mais traduites via le microcode en plusieurs instructions implémentées dans le silicium.
Le microcode ( "magasin de contrôle" ) est une donnée qui réside dans une mémoire volatile ou non volatile - généralement une mémoire assez petite mais très large, dont les signaux de sortie de données sont câblés au signal de contrôle entrées d'unités fonctionnelles matérielles parallèles, logique de commande aléatoire, etc. Les entrées d'adresse de la mémoire du microcode sont fournies par une machine à états qui parcourt un mot de mémoire ("instruction de microprogramme") à la fois, pour effectivement séquencer les signaux de commande d'un ou plusieurs blocs matériels. Ce matériel multiplexe dans le temps et permet aux opérations complexes d'être implémentées avec beaucoup moins de logique aléatoire.
Dans les microprocesseurs modernes, il peut exister une hiérarchie d'unités de microcode/séquence nécessaires pour résumer la microarchitecture de silicium physique en une famille d'architecture plus générale avec une interface commune de "code machine". Par exemple, il peut y avoir plusieurs couches de microcode/séquençage pour mettre en œuvre des décodeurs d'instructions et des unités à virgule flottante.
Par micrologiciel, on entend généralement tout logiciel/donnée résidant dans une mémoire non volatile, qui devrait être peu ou jamais modifiée. Ceci contraste directement les logiciels stockés ou plutôt écrits et exécutés depuis la mémoire système qui change constamment. Microcode fait spécifiquement référence à des données représentant un microprogramme pour commander en séquence le matériel.
Le microcode peut être implémenté dans un microprogramme/le microprogramme peut contenir un microcode, mais ils ne sont pas identiques.
J'ai suivi un cours de conception de base ISA, principalement dans l'étude et la conception d'un processeur RISC basé sur les concepts MIPS. Voici ce que je suis venu me rappeler
À ma connaissance, les blocs de base d’un processeur, tels que les registres, les ALU, les multiplexeurs et les modules de mémoire, nécessitent certains signaux pour leur bon fonctionnement. Vous appelleriez ces signaux vos signaux "d'assertion", car ce sont les signaux nécessaires pour faire fonctionner ces blocs. Les processeurs sont essentiellement un bloc spaghetti d’ALU, de modules de mémoire, de registres et d’autres matériels. Cela signifie que chaque CPU doit appliquer une certaine séquence de signaux de commande pour pouvoir fonctionner (par exemple, instructions élémentaires telles que ANDI, ORI, JMP, BNE, BEQ, etc.). J'éprouvais des sentiments mitigés lorsque j'ai dû affirmer moi-même les signaux (en parcourant littéralement toutes les instructions de MIPS) lors du test et du débogage d'un jeu d'instructions, car le rythme du programme ne m'avait rien appris sur les unités de contrôle à cette époque.
D'autre part, le langage assembleur se résume aux opcodes et à leurs opérandes dans l'instruction Word (essentiellement la largeur de votre bus de données). En termes de MIPS, les 6 premiers bits de votre instruction Word sont votre code opération. Par simple inspection mathématique, vous ne pouvez pas "affirmer" votre ALU, vous inscrire, la mémoire, les multiplexages .. essentiellement le reste de votre matériel avec 6 bits seulement.
Non, sauf si vous avez ... UN DECODEUR D'INSTRUCTIONS. Le décodeur d'instructions prend votre code d'opération et génère TOUS vos signaux d'assertion nécessaires au fonctionnement de votre matériel. Cependant, les décodeurs d'instructions diffèrent dans la mise en œuvre entre les architectures et, dans certains cas, sont programmables. Le microcode affecte la section programmable du décodeur d'instructions.
Je suis venu à croire que firmware est un terme général pour toute information intégrée au matériel. Dans certains cas, il ferait également référence au microcode étant donné que son flux binaire peut être codé et stocké dans du matériel tel qu'une mémoire EEPROM et une mémoire flash. La plupart du temps cependant, il s’agit de code compilé, asm ou même de flux binaires VHDL/Verilog utilisés dans les FPGA. Pour moi, le microcode ressemble à la sémantique utilisée pour spécifier les "signaux d'assertion" dans le processeur choisi.
Firmware est un code exécutable placé dans une ROM ou une autre mémoire non volatile.
L'objectif principal et principal du microprogramme est d'être présent au démarrage d'un processeur. Il doit donc être exécuté pour démarrer ou amorcer le système, quel qu'il soit. Dans le cas des PC, le micrologiciel est également utilisé pour fournir des services au système d'exploitation en cours d'exécution et contient également du code pour les contrôleurs intégrés qui contrôlent les ventilateurs, l'alimentation, etc., ainsi que du code pour le ME/PSP qui s'exécute en arrière-plan. .
Les périphériques dotés d'un microprogramme, tels que les disques durs, les périphériques USB, etc., sont dotés d'un processeur intégré.
Microcode n'est pas un code exécutable, mais un code utilisé par les installations internes d'un périphérique.
Il est chargé dans les processeurs Intel ou AMD avec une instruction WRMSR. Le chargement de microprogrammes dans un périphérique implique la programmation d'un ROM ou d'un support flash, ou bien la présence d'un petit programme de chargement dans le périphérique pour accepter le microprogramme.
Les mises à jour de micrologiciels et de microcodes appartiennent à la même catégorie. Ce que vous devez faire pour que le matériel fonctionne et que vous pouvez avoir besoin de mettre à jour de temps en temps, mais ce sont des choses très différentes.
Les instructions complexes dans de nombreux processeurs ne sont pas directement câblées dans le matériel, mais "exécutées" par une installation plus petite semblable à un processeur dans le processeur principal. Microcode contrôle ces opérations. Cela remonte au moins au Motorola 68000 qui avait un "MicroROM" contenant un microcode.
Personne d'autre que les processeurs Intel ou AMD ne sait ce que le microcode contrôle réellement ou fait, car ils ne communiquent pas les détails. Il y a des tentatives pour le pirater. Référence .
Dans la pratique, les mises à jour du microcode sont essentiellement utilisées pour désactiver les instructions qui posent des problèmes sur les modèles/processeurs de processeurs connus, et les derniers processeurs d'Intel nécessitent souvent au moins une mise à jour du microcode avant de fonctionner de manière fiable.
Si vous avez des informations sur le 6502 décodage PLA ROM , le 6502 est un ancien processeur 8 bits et ses instructions. ont été séquencés/contrôlés par un PLA interne. Le PLA indiquerait en principe quelles parties de la puce étaient impliquées à chaque étape de chaque instruction (6502 instructions vont de 2 à 7 cycles). C’est loin, bien avant les choses comme la mise en cache, l’architecture superscalaire, la prédiction de branche, etc. Je ne sais pas si le microcode sur les processeurs modernes contrôlerait quelque chose comme ce PLA.
Terminologie
Je répondrai moi-même en utilisant uniquement le contexte d'utilisation dans cette ce pdf .
Firmware - Microcode is mis à jour via un chemin fourni par le microprogramme de la CPU.
"En règle générale, un correctif de microcode est téléchargé dans la CPU par le microprogramme de la carte mère (par exemple, BIOS ou UEFI) ou par le système d'exploitation au cours du processus de démarrage initial."
Microcode - est lui-même les données utilisées par "l'Instruction Decode Unit (IDU)". Un IDU peut être soit câblé _ ou microcodé. Microcodé dans ce contexte signifie simplement programmé.AUSSIsignifie "la pluralité de microcodes." L'IDU
L'IDU joue un rôle central dans l'unité de contrôle et génère des signaux de contrôle en fonction du contenu du registre d'instructions.
Macro-instruction Une instruction envoyée à l'IDU à décoder, peut renvoyer toute quantité de Micro-instructions.
Micro-instruction un "mot de contrôle" précalculé, tous les états et instructions à exécuter pendant un cycle d'horloge. Envoyé à la CPU pour générer le signaux de commande.
Donc, dans ce contexte, vous mettriez à jour le microcode avec un firmware. Vous enverriez des macro-instructions à l'IDU microcodé pour résoudre la macro-instruction en une "micro-instruction" à exécuter sur la CPU, qui les transformera en signaux de commande.
Ma lecture de ce
Le microcode est données, mais met à jour le microcode est terminé à travers firmware. Et déroutant parce que vous parlez de ce qui équivaut essentiellement à une table de recherche interne, elle est certainement aussi elle-même firmware en ce sens qu'elle est essentiellement stockée sur la puce et utilisée dans le flux d'exécution de celle-ci. Je pense que vous pouvez faire valoir que General MIDI, le matériel PostScript et les signaux de commande des terminaux non intelligents sont également interprétés dans le même sens, dans le matériel, et que quelque chose prend l'instruction et génère finalement " signaux de contrôle " dans un processus d’interprétation.
Il semble que nous ayons un nom spécial pour ces processus et composants dans la CPU: "IDU" sur une CPU et un nom pour la table d'entrée spécifique utilisée par l'IDU qui contient toutes les "microinstructions": le "microcode". Les informations sur ce processus sont propriétaires et fermées. Je suppose que cela est analogue à toute autre technologie des modems (avec ATDT et similaires sur un modem Hayes), aux cartes MIDI, mais nous ne nommons pas la table de recherche spécifique "microcode", mais utilisons plutôt la terme générique "firmware" pour le processus de clignotement et la totalité de la charge utile stockée sur une puce.