Je me pose une question en ce moment à propos des processeurs. Si j'ai bien compris, le processeur peut effectuer des opérations relativement simples grâce aux jeux d'instructions (mov, addition, soustraction etc.).Cependant, ces instructions sont-elles contenues dans le processeur lui-même, ou dans le compilateur de l'assembleur qui le traduit en language machine?
J'ai beaucoup de mal à me représenter la transition assembleur à Jeu d'instruction processeur. Comment l'assembleur en lui-même peut faire en sorte que le CPU reçoit des bits et les traites comme des instructions?
Je me doute que c'est une question qui prendrais du temps à y répondre, mais j'aimerais surtout savoir comment se passe la transition Assembleur écrit, et Processeur et savoir si les jeux d'instructions sont dans le compilateur ou le CPU. Si les jeux d'instructions sont dans le compilateur, ça voudrais dire qu'il faut un compilateur differents par architecture de CPU différente? Sinon si les jeux d'instructions sont programmés dans le CPU, elles sont contenus dans la ROM du CPU?
Ces instructions sont-elles contenues dans le processeur lui-même, ou dans le compilateur de l'assembleur qui le traduit en language machine ?
Déjà, il y a quelques mots de vocabulaire à décrire (afin de mieux comprendre par la suite) :
Processeur : composant matériel chargé d'exécuter les instructions qui lui sont envoyées sous forme "d’impulsion électrique" (c'est grossièrement dit, mais c'est plus ou moins le cas) ;
Compilateur : programme dont le rôle est de compiler (traduire) du code haut niveau en code bas niveau (Java → bytecode | C → asm) ;
Assembleur : langage de bas niveau qui transforme du code lisible par l'Homme en code lisible par la machine (abc → 0011001) ;
Langage machine (aussi appelé OPCODE à tort (voir plus bas)) : suite de bits interprétée par le processeur.
Comment fonctionne un compilateur
Le compilateur "traduit" du code haut-niveau en code plus bas-niveau; exemple :
// C
void foo() {
int a = 8;
int b = 2;
int c = a + b;
}
Ce code est donc l'assembleur généré par notre code C, plus haut niveau. Chacunes de ces instructions à une correspondance en langage machine. Par exemple :
push rbp
mov rbp, rsp
correspond à ça :
4004d255
4004d348 89 e5
On a souvent l'habitude de parler (ou plutôt d'entendre) du terme "binaire". La forme que tu vois là est encore un niveau au-dessus, mais une simple conversion HEX→BIN permet d'obtenir le "résultat final" :
Enfin, cette forme-là en s'en fout un peu, et elle n'est d'ailleurs pas réellement représentative, car incorrecte.
Mais, comme tu le vois, l'assembleur n'est qu'un modèle figuratif (compréhensible par l'Homme) du réel code machine (abstrait pour nous) généré (d'où le nom : il assemble les instructions (il existe d'ailleurs plus d'un langage assembleur)).
Comment sont exécutées les instructions par le processeur
Tout d'abord, les instructions qui doivent être exécutées par le processeur sont stockées dans la mémoire vive, puis traitées :
(C'est un schéma, donc c'est évidemment simplifié).
Revenons sur notre exemple de code assembleur :
mov rbp, rsp ; instruction pris au pif pour l'exemple
Cette ligne copie le contenu du registre RSP dans le registre RBP.
Lorsque le processeur arrive à cette instruction (sous forme de bits), il va considérer tout ce qu'il y a avant la virgule comme instruction OPCODE qui va agir ensuite sur tout ce qu'il y a après la virgule, c'est-à-dire les données (les données sont représentées par un pointeur d'adresse en mémoire, il n'y aura jamais de données brutes lues par le processeur (du moins je ne pense pas)), dans ce cas-ci : RSP.
Il effectuera donc l’opération indiquée sur les données (dans ce cas, une copie/affectation de valeur).
Qu'est-ce qui défini une instruction
238 a écrit:
Je voudrais savoir si les jeux d'instructions sont dans le compilateur ou le CPU.
Comme dit plus haut, le compilateur ne fait que traduire du code, le jeu d'instructions n'est donc pas dans le compilateur, mais... ni directement dans le CPU !
Un processeur "sait" que le premier octet qui est en cours d'exécution est toujours une instruction OPCODE, la suite d'instructions qui suit l'opcode (lui-même compris) est envoyée, par l'intermédiaire d'un bus interne (Bus : sorte de câble électrique miniature qui sert aux transports de données | internes : contenu dans le processeur), dans ce qu'on appelle un "décodeur d'instruction". Ce décodeur identifie la suite, et le processeur effectue alors les opérations qui doivent être exécutées par rapport aux données.
Comment fonctionne le décodeur d'instruction
Le décodeur d'instruction du processeur est un circuit qui a pour but de transcoder (→ reproduire) une instruction (c f: dernier exemple) dans la micro-mémoire du processeur (et oui, il y en a là-dedans...) C'est dans cette micro-mémoire que se situe le jeu d'instructions. Ce jeu n'est pas un code, mais une série de ports logique :
C'est grâce aux impulsions électriques envoyées (0 → pas de courant (fermé) | 1 → du courant (ouvert)) et aux bus liés avec l'entrée, des/les ports logique, et la sortie que l'on arrive à avoir un résultat, comme une opération standard (l'instruction or ici) :
[0][0] → fermé | fermé → false
[0][1] → fermé | ouvert → true
[1][1] → ouvert | ouvert → true
Et puisque tous les processeurs ne sont pas identiques, effectivement, le code assembleur est traduit et exécuté différemment d'une machine à l'autre, mais le principe est fondamentalement le même.
- Edité par vanaur 9 mai 2018 à 17:53:47
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Comme dit plus haut, le compilateur ne fait que traduire du code, le jeu d'instructions n'est donc pas dans le compilateur, mais... ni directement dans le CPU !
Un processeur "sait" que le premier octet qui est en cours d'exécution est toujours une instruction OPCODE, la suite d'instructions qui suit l'opcode (lui-même compris) est envoyée, par l'intermédiaire d'un bus interne
- Edité par vanaur il y a 27 minutes
Bonjour vanaur et merci pour avoir pris le temps de me répondre
Si j'ai bien compris, les jeux d'instructions processeurs sont représentés par l'OPCODE, en fonction de sa valeur, le processeur va soit swap, mov ou additionne (etc..) des valeurs? Cela veut donc dire que les jeux d'instructions sont en réalité représentés par l'architecture du processeur elle-même (la façon dont il est cablé), et non pas par des "instructions" en mémoire?
Si j'ai bien compris, les jeux d'instructions des processeurs sont représentés par l'OPCODE, en fonction de sa valeur, le processeur va soit swap, mov ou additionne (etc..) des valeurs?
Non, une instruction d'OPCODE n'est pas évaluée par la donnée qu'il traite, mais c'est justement la donnée qui sera traitée en fonction de l'instruction.
238 a écrit:
Cela veut donc dire que les jeux d'instructions sont en réalité représentés par l'architecture du processeur elle-même (la façon dont il est cablé), et non pas par des "instructions" en mémoire?
C'est bien ça (en gros hein), c'est l'architecture qui définit son jeu d'instructions. Il y en a plusieurs, et gère les choses de manière différente, ou en ajoute d'autres.
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...