Fonctionnement des ordinateurs de zéro

Fonctionnement des ordinateurs de zéro

a marqué ce sujet comme résolu.

Si je n'ai pas commencé le cours par cet extrait, c'est parce que les chapitres précédents permettent de se familiariser avec les concepts de mémoire, de bits, de traitement, etc. De plus, l'organisation actuelle permet une continuité entre les chapitres. Si j'avais commencé avec ce chapitre (c'était ce qui était fait sur l'ancienne version récupérée du SDZ), le passage au binaire ou aux circuits donnait l'impression de passer du coq à l'âne. Avec l'organisation actuelle, on passe d'un chapitre à l'autre d'une manière qui est un peu plus fluide, les transitions étant moins abruptes.

+0 -0

Si j'avais commencé avec ce chapitre (c'était ce qui était fait sur l'ancienne version récupérée du SDZ), le passage au binaire ou aux circuits donnait l'impression de passer du coq à l'âne.

Je ne comprends pas pourquoi. On aurait le cheminement suivant, qui me parait tout à fait fluide.

  • Un ordinateur est une machine pour manipuler l'information
  • Pour cela, il dispose d'IO, d'une mémoire et d'un CPU
  • Le contenu de l'extrait Les composants d'un ordinateur
  • On a vu qu'un ordinateur manipulait l'information, mais comment la représente-t-il ?
  • Le contenu de Tout est nombre

Si je n'ai pas commencé le cours par cet extrait, c'est parce que les chapitres précédents permettent de se familiariser avec les concepts de mémoire, de bits, de traitement, etc.

Peut-être qu'il serait possible de faire une analogie avec l'être humain ? On comprendrait facilement ces notions-là. Pour ce qui est des bits, tu pourrais dans un premier temps parler d'information, sans expliquer sous quelle forme on la manipule.

+0 -0

En même temps, la notion d'information est assez floue et peu intuitive dans le langage courant. Pas sûr qu'en parler clarifierait le propos. Après, c'est subjectif, mais je n'avais pas du tout aimé l'approche avec le chapitre 5 en premier et je ne pense pas être vraiment capable de faire quelque chose de crédible avec.

Et je ne comprends pas cette histoire d'analogie avec un être humain.

+0 -0

En même temps, la notion d'information est assez floue et peu intuitive dans le langage courant. Pas sûr qu'en parler clarifierait le propos.

C'est pas faux.

Et je ne comprends pas cette histoire d'analogie avec un être humain.

C'était par rapport à :

Si je n'ai pas commencé le cours par cet extrait, c'est parce que les chapitres précédents permettent de se familiariser avec les concepts de mémoire, de bits, de traitement, etc.

Avec une analogie, on comprend aisément ce qu'est une mémoire, un traitement, etc. Mais bon, l'idée est de toute façon abandonnée.

+0 -0

I.4.Hiérarchie mémoire

Une histoire de vitesse

et des mémoires plus importante, mais plus lentes

Histoire d'éviter toute mésinterprétation du propos, il me semble préférable de dire "des mémoires de capacité plus importante".

Il se peut que certains processeurs se passent de caches, de registres, ou de mémoires de masse.

La formulation est bizarre, puisque tu parlais jusque-là d'ordinateur, et maintenant de processeur.

Mais sur certains ordinateurs, la mémoire principale est conceptuellement séparée en deux :

Conceptuellement, ça veut dire que physiquement, c'est le même composant ? Il me semble intéressant d'insister là-dessus pour bien comprendre la différence entre les architectures Von Neumann et Harvard.

une mémoire ROM qui stocke le programme et les constantes, nommée la mémoire programme ;

Je ne comprends pas trop ce que tu désignes par le programme. Vu qu'on a une mémoire dans laquelle on ne peut écrire, j'aurais tendance à dire que tu parles du BIOS, mais qu'en est-il des programmes ordinaires, qu'on écrit en Python ou en C ?

Une adresse bien précise va ainsi correspondre soit à la mémoire RAM, soit à la mémoire ROM, mais aux deux

Mais pas aux deux.

Vision de la mémoire par un processeur sur une architecture Von Neumann

J'indiquerais le numéro de la première case mémoire RAM, qu'on constate bien qu'il est le successeur du numéro de la dernière case ROM. Tu aurais un truc du genre :

Num Type
0 ROM
1 ROM
… ROM
n ROM
n + 1 RAM
… RAM

L'avantage de cette architecture est qu'elle permet de charger une instruction et une donnée simultanément.

Je ne comprends pas trop cela. Veux-tu dire qu'on n'a pas besoin de se demander dans quelle mémoire il faut chercher la donnée, puisque le bus choisi nous le dit directement ? Mais il faut bien choisir le bus, donc en fin de compte, ça revient au même, non ?

Caches et Local stores

Le troisième niveau est intermédiaire entre les registres et la mémoire

principale

Dans ce niveau, on peut trouver deux types de mémoires : soit des caches, soit des Local Stores.

On ne sait pas trop comment prendre le "soit…soit". Du moins, je me suis demandé si c'était une erreur de ta part ou si les mémoires étaient incompatibles.

Une mémoire cache n'est jamais adressable !

Je n'avais pas compris cela avant de lire la suite : je pensais que ça signifiait qu'on ne pouvait lui demander de lire la case avec telle adresse.

Lorsque le processeur veut ainsi accéder à une case mémoire en RAM (en lecture ou en écriture), il va envoyer l'adresse de cette case sur le bus. Celle-ci sera interceptée par les circuits chargés de gérer le cache qui regarderont alors si le cache contient une copie de la case à manipuler. Si c'est le cas, on lit ou écrit la donnée dans le cache. Dans le cas contraire, on accède à la mémoire RAM.

Pour que la mémoire cache soit plus efficace que la RAM, il faut qu'elle ne contienne que certaines cases de celle-ci. Comment détermine-t-on lesquelles ? En fait, j'ai du mal à comprendre l'intérêt du cache.

Et cela change tout : vu que ces Local Store sont adressables, ils ne sont plus gérés automatiquement par le processeur.

Je ne comprends pas cela. En fait, je crois que je ne comprends pas ce que signifie être adressable. Tu emploies ce terme pour la première fois dans le chapitre quand tu introduis les caches.

Mémoires de masse

On peut ainsi facilement installer ou supprimer des programmes sur notre périphérique, en rajouter, en modifier, les mettre à jour sans que cela ne pose problème.

Le terme "programme" fait un peu bizarre. De manière générale, on a plutôt tendance à stocker des photos, des fichiers textes, etc. sur une clé USB.

J'ai du mal à avoir une vision globale de l'utilité de chaque mémoire. En effet, tu dis juste comment elles fonctionnent (et les ordonnes), sans trop expliquer pourquoi elles sont là, si ce n'est qu'elles sont plus rapides que leur successeur.

De plus, j'ai du mal avec la partie sur les caches. Je ne saurais pas trop dire pourquoi autrement qu'en relevant certains points, comme ci-dessus. Il faudra que je revois complètement cette partie à tête reposée, surtout le passage sur les Local Stores.

Au passage, pourquoi parler de cela maintenant plutôt que dans la partie sur la mémoire ?

+0 -0

II.1.Des mémoires en veux-tu, en voilà !

Préfixe Quantité Puissance de deux

"Quantité" n'est pas très précis. Est-ce le nombre de bits ?

Généralement, lire une donnée ne prend pas le même temps que l'écrire

La lecture (ou l'écriture) de (dans) deux cases mémoire différentes prend-elle le même temps ?

Les programmes et le système d'exploitation sont placés sur une mémoire qui ne s'efface pas quand on coupe le courant, contrairement à votre document Word non-sauvegardé.

Une petite phrase pour introduire le tableau du dessous ? :)

Ces mémoires sont appelées des mémoires PROM.

Peut-être pourrais-tu introduire la liste qui suit ?

Les FROM sont fournies intégralement vierges, et on peut les reprogrammer une seule fois ;

Le terme "reprogrammer" est un peu ambigu, du fait du "re". Peut-on encore écrire (une fois) dans une FROM après l'avoir remplie ?

  • les EPROM s'effacent avec des rayons UV et peuvent être reprogrammées plusieurs fois de suite ;
  • certaines EPROM peuvent être effacées par des moyens électriques : ce sont les mémoires EEPROM.

Tu parles d'effacement, mais comment se passe la (re)programmation ?

qui utilisent souvent pas mal de transistors (au minimum 6, voire plus), pas mal de place

Je dirais "donc pas mal de place". :)

Les DRAM sont donc plus lentes que les SRAM

Je ne comprends pas cela.

II.1.Donnée, où es-tu ?

Mémoires Séquentielles

On parcourait la mémoire dans l'ordre, en commençant par la première donnée : c'est l'accès séquentiel.

Dans l'ordre, ça veut dire dans l'ordre des cases mémoires physiques, ou bien dans un ordre défini via des successeurs, comme pour les listes chainées ?

Mémoires FIFO

Mémoires FIFO

Il me semble important de mentionner le terme "file".

Mémoires LIFO

Ces mémoires sont des mémoires dans lesquelles les données sont triées par ordre d'arrivée. Les données sont donc écrites dans la mémoire unes par unes, et placées dedans au fur et à mesure.

Je ne comprends pas trop cela. Du moins, ça ne me semble pas propre aux mémoires LIFO : ce qui change avec ces dernières, je crois, c'est juste l'ordre de lecture.

Mémoires adressables par contenu

Au lieu d'envoyer l'adresse pour accéder à la donnée, on va envoyer la donnée pour récupérer son adresse.

Du coup, je ne comprends pas trop à quoi correspond l'adresse retournée, ni à quoi ça sert de la retourner.

Cela peut paraitre bizarre, mais ces mémoires sont assez utiles dans certains cas de haute volée.

Je ne comprends pas ce que tu veux dire par "haute volée".

Il est possible que plusieurs données différentes aient le même Tag
…
A chaque accès mémoire, on envoie le Tag de la donnée à modifier, et la mémoire accède alors directement à la donnée.

Comment savoir quelle donnée accéder ? Si j'ai bien compris, c'est l'équivalent des tables de hachages (ou dictionnaires en Python, par exemple), pour lesquels les clés sont uniques.

II.1.Une histoire de bus

Il existe alors une petite astuce pour économiser des fils

Tu parles des broches pour expliquer comment on connecte les bus à la mémoire, mais tu n'expliques pas vraiment la nature des bus. Du coup, on ne comprend pas trop cette phrase.

Bus multiplexé avec bit ALE

Ca rejoint la remarque précédente, mais je remarque trois groupes de fils sur le schéma. Du coup, je ne comprend pas trop en quoi il y a réduction du nombre de fils.

Par contre, les lectures ne posent pas de problèmes : bus multiplexé ou pas, on récupère la donnée lue après l'envoi de l'adresse.

Il pourrait être intéressant d'expliquer pourquoi on ne continue pas dans la logique du bus multiplexé et ne garde pas qu'un seul bus, s'occupant de fournir à la fois la commande, l'adresse et les données. J'imagine que c'est parce que ça ralentirait non seulement l'écriture, mais aussi (et surtout) la lecture.

Certaines mémoires n'hésitent pas à câbler un maximum de fils pour gagner en performances : la mémoire est reliée à plusieurs bus, qui permettront de transférer une donnée chacun.

Sans avoir lu ce qui suit le schéma, je n'ai pas compris ce passage. Peut-être pourrais-tu suivre le cheminement inverse ?

  • Bus multiplexé ou pas, un seul composant à la fois peut accéder à la mémoire
  • Pour pallier cela, on y connecte plusieurs bus
  • On parle alors de mémoires multiports, parce que…

Ces mémoires sont appelées des mémoires multiports, vu que chaque bus est connecté sur la mémoire sur ce qu'on appelle un port.

La notion de port n'est pas très très claire, parce qu'on ignore la nature d'un bus, donc la manière de le connecter, mais aussi parce que tu parles plus haut de broches : quelle est la différence ?

Merci. :)

+0 -0

J'ai du mal à avoir une vision globale de l'utilité de chaque mémoire. En effet, tu dis juste comment elles fonctionnent (et les ordonnes), sans trop expliquer pourquoi elles sont là, si ce n'est qu'elles sont plus rapides que leur successeur.

Qu'est-ce qui te fait penser qu'il y a une autre chose à comprendre ?

De plus, j'ai du mal avec la partie sur les caches. Je ne saurais pas trop dire pourquoi autrement qu'en relevant certains points, comme ci-dessus. Il faudra que je revois complètement cette partie à tête reposée, surtout le passage sur les Local Stores.

Tu comprendras avec le chapitre sur le cache. Pour le moment, j'ai réduit un peu la partie sur les caches en indiquant que j'en parlerais plus en détail dans quelques chapitres.

Au passage, pourquoi parler de cela maintenant plutôt que dans la partie sur la mémoire ?

Pour éviter d'avoir un chapitre avec très peu d'extraits, ou des extraits trop courts ? C'est juste une histoire d'esthétique du plan de cours.

Pour les bus, c'est expliqué au chapitre précédent : ensemble de fils sur lesquels on transmet des informations (données ou instructions), souvent codées en binaire (un bit par fil).

+0 -0

Qu'est-ce qui te fait penser qu'il y a une autre chose à comprendre ?

Une question que je me pose, par exemple, c'est pourquoi ne pas ajouter un niveau entre la mémoire principale et celle de masse ?

Mais à bien y penser, je crois que ce sont les caches qui m'ont perturbé. En effet, on a naturellement :

  • Registres : mémoires internes au CPU pour les calculs
  • Mémoire de masse : mémoire non volatile, pour stocker des données de façon "permanente", sur le long terme
  • Mémoire principale : entre les deux, pour stocker les données relatives à une session d'utilisation de la machine (du démarrage à l'arrêt)

Sauf qu'on ajoute les caches, ce qui amène à la qestion du pourquoi.

+0 -0

Une question que je me pose, par exemple, c'est pourquoi ne pas ajouter un niveau entre la mémoire principale et celle de masse ?

Parce qu'on en a pas besoin, tout simplement : les gains en performances seraient trop faibles pour que ce soit rentable. Je signale d'ailleurs que la majorité des accès effectués par un programme n'atterrissent pas sur le disque dur : un programme ne manipule explicitement que la RAM et les registres (le CPU redirigeant certains accès dans le cache). Peu de programmes utilisent massivement des fichiers, et encore moins pour ce qui est de mémoriser temporairement des données.

Et c'est peut-être aussi parce qu'on a pas la technologie pour : entre les mémoires de masse magnétiques et des mémoires principales électroniques à base de DRAM, on n'a pas d'intermédiaires. Mis à part les SSD à base d'EEPROM FLASH, dans un certain sens.

Sinon, un autre indice sur pourquoi on rajoute tel ou telle mémoire à tel endroit dans la hiérarchie mémoire :

Type de mémoire Temps d'accès Capacité
Registres 1 nanosecondes (10-9), voire moins Quelques bits, entre 1 à 512
Caches 10 - 100 nanosecondes (10-9) Milliers ou Millions de bits
Mémoire RAM 1 microsecondes (10-6) Milliards de bits
Mémoires de masse 1 millisecondes (10-3) Centaines de Milliards de bits

Sauf qu'on ajoute les caches, ce qui amène à la question du pourquoi.

Parce qu'on en a besoin, tout simplement. Utiliser des caches rend l'ordinateur beaucoup plus rapide sans renchérir son cout, pourquoi s'en priver ?

+0 -0

Utiliser des caches rend l'ordinateur beaucoup plus rapide sans renchérir son cout

Peut-être pourrais-tu le dire explicitement ? Tu pourrais par exemple suivre le cheminement suivant.

  • On a des mémoires de masse, que tout le monde connait (clé USB, etc.), pour stocker l'information sur le long terme
  • Mais celles-ci sont très lentes, donc on ajoute une mémoire principale
  • Mais le processeur a souvent besoin de stocker de petits résultats intermédiaires pour ses calculs. On ajoute donc des registres.
  • Enfin, il existe un quatrième type de mémoire : les caches. Ils rendent l'exécution beaucoup plus rapide sans augmenter le coût. On reviendra dessus, mais sachez que dans les grandes lignes ils fonctionnent comme ça : …
+0 -0

J'ai repris la première partie du début, et je me suis dit que l'extrait I.5.Les composants d'un ordinateur pourrait être intégré au premier chapitre. Tu aurais :

  • Tout est nombre : représentation de l'information avec des nombres
  • Analogique, numérique et binaire : les manières de coder l'information
  • Les composants d'un ordinateur : manipulation générale de l'information

Quitte à renommer certains composants. Le reste de la première partie du tutoriel expliquerait comment on manipule l'information concrètement, électriquement.

I.5.Hiérarchie mémoire irait alors dans la partie sur la mémoire.

+0 -0

Une bonne partie des remarques précédente a causé quelques légères modifications dans le cours. J'ai aussi ajouté des indications sur les chapitres qui peuvent être dispensables en premières lecture. Sur deux chapitres, j'ai ainsi ajouté une balise information qui prévient que le chapitre en question est relativement technique, peu intéressant en première lecture, voir franchement compliqué, et qu'il peut être passé en première lecture sans problèmes. A vous de voir si c'est une bonne chose ou pas.

+0 -0

Serait-il possible d'avoir ton opinion sur mon dernier message ? Il me semble personnellement très intéressant de parler rapidement de la structure générale d'un ordinateur. Pour avoir une vision globale premièrement, mais aussi pour rassembler dans le premier chapitre les points peu techniques. En effet, je crois que beaucoup de personnes se posent cette question, mais n'ont aucun intérêt pour les multiplexeurs ou les bascules : les premier et dernier chapitres de la première partie leur conviendraient donc tout à fait.

+0 -0

C'est non : j'ai bien dit que faire comme ceci ne m'avait vraiment pas convaincu quand j'ai essayé, dont je laisse le plan en l'état pour les premiers chapitres.

Et ceux qui se posent ce genre de question et veulent une réponse rapide (est-ce vraiment possible, d'ailleurs ?) n'ont pas besoin de lire mon cours : la consultation de quelques pages wikipédia bien choisies, ou d'un autre cours nettement plus simple, leur suffira amplement. Je ne me suis pas tapé la rédaction de 45 chapitres pour que leur lecture soit abandonnée après quelques chapitres par des lecteurs qui ont eu ce qu'ils voulaient. Dans ces conditions, me demander de refondre mon cours dans ce but recevra toujours la même réponse : c'est non !

+1 -0

I'm back.

Je saute la deuxième partie parce la troisième correspond avec ce que j'étudie en cours en ce moment. J'espère que ce n'est pas trop gênant au niveau des pré-requis.

Registres : contenu et adressage

Le registre d'état contient plusieurs bits qui ont chacun une utilité particulière. Ce registre est très différent suivant les processeurs, mais certains bits reviennent souvent, comme des bits qui stockent les résultats d'instructions de comparaisons ou de tests, le bit d'overflow : prévient quand le résultat d'une instruction est trop grand pour tenir dans un registre, le bit null : précise

J'ai eu du mal à comprendre cela, à cause de la forme je pense (avec les virgules, on ne sait plus trop ce qui correspond à quoi). Plusieurs questions :

  • Peut-on avoir des groupes de bits, c'est-à-dire stocker une information sur plusieurs bits ? Tu dis en effet que chaque bit a une signification particulière, mais pourrait-on avoir un truc du genre "chaque paire de bits".
  • Je ne comprends pas l'enchaînement suivant : "souvent, comme des bits qui stockent les résultats d'instructions de comparaisons ou de tests, le bit d'overflow". Un bit d'overflow (et ceux qui suivent) est-il un cas particulier de "bits qui stockent les résultats d'instructions de comparaisons ou de tests" ?

Ces registres contiennent des constantes assez souvent utilisées. Par exemple, certains processeurs possèdent des registres initialisés à zéro pour accélérer la comparaison avec zéro ou l'initialisation d'une variable à zéro. On peut aussi citer certains registres flottants qui stockent des nombres comme π, ou e pour faciliter l'implémentation des calculs trigonométriques).

Le contenu de tels registres est-il constant ? Autrement dit, puis-je un coup stocker dans un registre $e$, puis une autre fois $\pi$, ou bien aurai-je deux registres différents dont le contenu ne bouge pas ? Autrement dit, le cas de figure suivant est-il possible : quand je travaille sur un algo avec des exponentielles donc je stocke dans mon registre constant $e$, puis quand je manipule des fonctions trigonométriques, j'y stocke $\pi$.

Peut-être pourrais-tu fournir un exemple d'exécution de programme, en indiquant le contenu de chaque registre au cours du temps ?

Lire ou écrire dans le Program Counter permet de remplacer les branchements par un simple échange de données entre registres : il suffit d'écrire l'adresse à laquelle brancher dans le Program Counter.

Je ne comprends pas cela.

Il existe une dernière solution, assez peu utilisée. Sur certains processeurs assez rares, on peut adresser les registres via une adresse mémoire.

Quelle est la différence entre une adresse mémoire et un numéro ?

Instructions : c'est quoi ?

Pour simplifier, on peut classer les instructions en deux grands types :

J'en lis trois. :P

et des instructions de comparaison et de branchement.

Je n'avais pas compris le terme "branchement" à la première lecture. Peut-être ajouter "conditionnel" ?

Les instructions d’accès mémoire permettent de copier ou d'échanger des données entre le processeur et la mémoire. On peut ainsi copier le contenu d'un registre en mémoire, charger une donnée de la RAM dans un registre, initialiser un registre à une valeur bien précise, etc. Il en existe plusieurs, les plus connues étant les instructions :

La question qu'on risque de se poser, c'est : mais comment fait le processeur pour comprendre "LOAD" ? Il me semble intéressant de dire que c'est juste du sucre syntaxique pour désigner une instruction binaire.

De plus, je me demande comment ça fonctionne en pratique. J'en ai une petite idée, mais pour clarifier la question : comment, à la lecture de l'instruction binaire rattachée à LOAD, le processeur fait-il pour savoir ce qu'il doit faire ? Autrement dit, comment passe-t-on de "le processeur lit l'instruction LOAD" à "la contenu associé à l'adresse fournie est stockée dans tel registre".

Vient ensuite le ET bit à bit, qui agit sur deux nomnbres. Sur ces deux nombres, il va prendre les bits qui sont à la même place et va effectuer un ET (léopration effectuée par la porte logique ET). Exemple : 1100.1010=1000.

Tu pourrais centrer l'exemple et mettre en gras le "ET bit à bit", afin que ce soit plus lisible.

Mais lorsqu'on effectue un décalage à droite, certains bits vont sortir du résultat et être perdus : le résultat est tronqué ou arrondi vers zéro.

Je ne comprends pas le "ou arrondi vers zéro". Le résultat est toujours tronqué, non ?

Les instructions de rotation sont similaires aux décalages, à part que les bits qui sortent du nombre d'un coté rentrent de l'autre et servent à boucher les trous.

A quoi ça sert ?

Merci.

+0 -0

Pour répondre à Vayel.

J'ai eu du mal à comprendre cela, à cause de la forme je pense (avec les virgules, on ne sait plus trop ce qui correspond à quoi).

On peut pas mettre de listes dans un tableau simple, sinon je l'aurais fait.

  • Peut-on avoir des groupes de bits, c'est-à-dire stocker une information sur plusieurs bits ? Tu dis en effet que chaque bit a une signification particulière, mais pourrait-on avoir un truc du genre "chaque paire de bits".

Oui, par exemple voici ce que contient le registre d'état sur x86 : EFLAGS.

  • Je ne comprends pas l'enchaînement suivant : "souvent, comme des bits qui stockent les résultats d'instructions de comparaisons ou de tests, le bit d'overflow". Un bit d'overflow (et ceux qui suivent) est-il un cas particulier de "bits qui stockent les résultats d'instructions

Non.

Le contenu de tels registres est-il constant ?

Oui.

Peut-être pourrais-tu fournir un exemple d'exécution de programme, en indiquant le contenu de chaque registre au cours du temps ?

Pourquoi pas, mais il faudrait que je familiarise le lecteur avec un jeu d'instruction en particulier.

Quelle est la différence entre une adresse mémoire et un numéro ?

Le nom de registre reste à l'intérieur du processeur et n'est jamais transmis sur le bus d'adresse. De plus, la taille du numéro, en nombre de bits, n'est pas la même.

La question qu'on risque de se poser, c'est : mais comment fait le processeur pour comprendre "LOAD" ? Il me semble intéressant de dire que c'est juste du sucre syntaxique pour désigner une instruction binaire.

De plus, je me demande comment ça fonctionne en pratique. J'en ai une petite idée, mais pour clarifier la question : comment, à la lecture de l'instruction binaire rattachée à LOAD, le processeur fait-il pour savoir ce qu'il doit faire ? Autrement dit, comment passe-t-on de "le processeur lit l'instruction LOAD" à "la contenu associé à l'adresse fournie est stockée dans tel registre".

C'est expliqué dans les chapitres qui suivront. Pour le moment, considère ton CPU comme une boite noire dont on décrit le fonctionnement. Cette séparation architecture ASM et µarch a un but pédagogique.

Je ne comprends pas le "ou arrondi vers zéro". Le résultat est toujours tronqué, non ?

Cette troncature correspond mathématiquement (en décimal, si tu préfère) : soit à une troncature, soit à un arrondi. Ça dépend du nombre.

A quoi ça sert ?

Quand tu veux passer en revue un Byte bit par bit en utilisant un nombre minimal d'instructions, par exemple ? Peut-être que tu trouveras des exemples en lisant mon cours sur les bits à bits et le branch free code.

+0 -0

On peut pas mettre de listes dans un tableau simple, sinon je l'aurais fait.

Pas de souci. Par contre, tu peux jouer avec la ponctuation, en mettant des points-virgules au lieu de virgules.

C'est expliqué dans les chapitres qui suivront. Pour le moment, considère ton CPU comme une boite noire dont on décrit le fonctionnement. Cette séparation architecture ASM et µarch a un but pédagogique.

Peut-être le préciser en introduction ?

Cette troncature correspond mathématiquement (en décimal, si tu préfère) : soit à une troncature, soit à un arrondi. Ça dépend du nombre.

En fait, je ne vois pas quand on a un arrondi, puisqu'il me semble qu'on tronque tout le temps.

Quand tu veux passer en revue un Byte bit par bit en utilisant un nombre minimal d'instructions, par exemple ? Peut-être que tu trouveras des exemples en lisant mon cours sur les bits à bits et le branch free code.

Il me semble intéressant d'ajouter une note à ce sujet.

Merci pour tes retours. Je poursuis les miens :

Opcode et mode d'adressage

Dans ces conditions, difficile de faire la différence entre donnée et instruction.

La question qui me vient à l'esprit est : pourquoi ne pas les stocker à deux endroits différents ?

La suite de bits de l'instruction contient une sous-suite qui permet d'identifier l'instruction en question

Ca fait bizarre, puisque ça n'a pas de rapport avec le problème que tu mentionnes juste au-dessus : "Dans ces conditions, difficile de faire la différence entre donnée et instruction.". On s'attend à d'abord apprendre comment distinguer une instruction d'une donnée, puis les instructions entre elles.

Il arrive que certaines instructions soient composées d'un Opcode, sans rien d'autre : elles ont alors une représentation en binaire qui est unique. Mais certaines instructions ajoutent une partie variable pour préciser la localisation des données à manipuler.

Peut-être pourrais-tu donner des exemples d'instructions prenant ou non des paramètres ?

Reste à savoir comment interpréter cette partie variable : après tout, c'est une simple suite de bits qui peut représenter une adresse, un nombre, un nom de registre, etc.

On ne peut pas le déduire de l'opcode ? J'ai peut-être mal compris, mais pour moi, l'opcode est un nom de fonction, auquel on joint des paramètres potentiels.

Avec l'adressage immédiat, la partie variable est une constante

Je ne suis pas sûr de comprendre cela. Veux-tu dire que le paramètre est toujours le même (ce qui n'aurait pas grand intérêt) ou plutôt qu'on stocke sa valeur directement dans l'instruction ?

Le fait qu'on n'ait qu'un seul opérande m'intrigue, puisqu'une addition est une opération binaire.

Qu'est-ce que "EAX" ? Le nom du registre contenant 1002 ?

Sans ce mode d'adressage, on serait obligé d'utiliser une instruction utilisant le mode d'adressage direct, et de modifier l'adresse incorporée dans l'instruction avec du self-modifying code. Imaginez l'horreur.

Pourquoi est-ce une horreur ?

Je ne comprends pas trop le schéma. Pourquoi as-tu dans un registre une adresse (1002) et dans les autres des valeurs (17, 610, etc.) ?

De plus, je ne suis pas certain de ce sur quoi pointe la flèche "+1".

On doit donc calculer son adresse à partir de l'indice et d'autres informations.

Je ne comprends pas le "d'autres informations". Veux-tu dire par là "l'adresse de la case d'indice 0" ?

Pour éviter d'avoir à calculer les adresses à la main avec le mode d'adressage register indirect, on a inventé un mode d'adressage pour combler ce manque : le mode d'adressage Indexed Absolute.

Qu'apporte le mode d'adressage Indexed Absolute par rapport au Register Indirect Autoincrement ?

J'ai du mal à voir à quoi correspond le second opérande.

La majorité des tableaux sont des tableaux dont l'adresse n'est pas connue lors de la création du programme : ils sont déclarés sur la pile ou dans le tas, et leur adresse varie à chaque exécution du programme. On peut certes régler ce problème en utilisant du self-modifying code, mais ce serait vendre son âme au diable !

J'ai eu du mal à comprendre cela, parce que je n'ai pas pensé au fait qu'on pouvait créer une instruction sur le tableau avant sa création (donc avant qu'on connaisse son adresse), ce qui nous oblige à mettre à jour son adresse une fois qu'il est créé. Un cas de figure aiderait.

Par exemple, voici ce que donnerais une structure composée d'un entier, d'un flottant simple précision, et d'un caractère

Tu pourrais donner un exemple de structure d'un point de vue programmation. A l'origine, je croyais que tu parlais des dictionnaires.

Calculer l'adresse d'un élément de notre structure se fait donc en ajoutant une constante à l'adresse de départ de la structure

Je vois ce que tu entends, mais la formulation est un peu étrange puisqu'on pourrait croire qu'il n'y a qu'une constante. Alors qu'en fait, c'est une constante par élément.

Encodage du mode d'adressage

Peut-être que tu pourrais insérer cette partie avant la liste des différents modes, puisqu'elle répond aux questions posée au début de ce message.

Les opérandes d'une instruction n'ont pas la même taille. Ce qui fait que nos instructions auront des tailles différentes, si elles utilisent des opérandes différentes.

Peut-être être plus explicite sur ce qui fait varier la taille. Celle de l'opcode est, j'imagine, constante, mais la présence ou non du mode d'adressage (de taille constante ?) influe sur la taille de l'instruction, tout comme celle des opérandes.

Les schémas aident globalement à comprendre, mais des exemples concrets seraient je pense plus explicites : je suis dans tel mode d'adressage, j'envoie telle instruction, que se passe-t-il pas-à-pas ? Après, il faut savoir que j'aime beaucoup les cas de figure pour illustrer les propos, donc mon conseil est probablement biaisé.

Merci. :)

+0 -0

La question qui me vient à l'esprit est : pourquoi ne pas les stocker à deux endroits différents ?

Vayel

Rappelle-toi des architectures Harvard.

On ne peut pas le déduire de l'opcode ? J'ai peut-être mal compris, mais pour moi, l'opcode est un nom de fonction, auquel on joint des paramètres potentiels.

Vayel

Pas toujours.

Et ton analogie avec les noms de fonction est fausse. Pour simplifier, chaque instruction devrait aussi préciser quelque chose qui joue un rôle similaire aux types des paramètres, si ce n'est que le jeu de types est assez restreint et très différent des types en programmation. C'est plus ou moins ce que permettent les modes d'adressage : ceux-ci permettent de savoir comment interpréter chaque paramètre, en disant s'il s'agit :

  • d'une adresse directe à la &variable du C (adressage direct) ;
  • d'un pointeur (adressage indirect) ;
  • d'une constante (adressage immédiat) ;
  • d'une variable (adressage inhérent) ;
  • etc.

Sur certains processeurs, tu peux voir les instructions comme des fonctions polymorphes, qui acceptent plusieurs types : tu es obligé de préciser les modes d'adressages hors de l'opcode. D'autres processeurs ont des instructions analogues aux fonctions des langages sans polymorphisme : l'opcode fait foi.

+0 -0

D'accord. Donc en fait, une instruction d'addition pourrait prendre peu ou prou les formes suivantes, et c'est le mode d'adressage qui nous dit de laquelle il s'agit ?

1
2
3
ADD n1 n2
ADD n_at_addr n
ADD n_at_addr1 n_at_addr2
+0 -0

Avec l'adressage immédiat, la partie variable est une constante

Je ne suis pas sûr de comprendre cela. Veux-tu dire que le paramètre est toujours le même (ce qui n'aurait pas grand intérêt) ou plutôt qu'on stocke sa valeur directement dans l'instruction ?

Il est dit que la partie variable est UNE constante, pas qu'elle EST constante.

Le fait qu'on n'ait qu'un seul opérande m'intrigue, puisqu'une addition est une opération binaire.

Dans les dessins, seule l'opcode et une partie variable/opérande sont indiqués, histoire d'alléger les schémas et de faciliter la compréhension. Je rajoute une note à ce propos.

Qu'est-ce que "EAX" ? Le nom du registre contenant 1002 ?

Va falloir que je rajoute quelques remarques sur l'ASM avant. C'est bien le nom du registre, mais écrit en ASM et non en langage machine.

Pourquoi est-ce une horreur ?

Crois-moi sur parole : le code ASM qui correspond est illisible.

Je ne comprends pas trop le schéma. Pourquoi as-tu dans un registre une adresse (1002) et dans les autres des valeurs (17, 610, etc.) ?

Comment tu fais la différence entre une valeur et une adresse dans un registre ?

Je ne comprends pas le "d'autres informations". Veux-tu dire par là "l'adresse de la case d'indice 0" ?

Oui, plus la taille d'une case (qui dépend de son type). J'en parle d'ailleurs dans le cours sur le langage C, à ce propos.

Qu'apporte le mode d'adressage Indexed Absolute par rapport au Register Indirect Autoincrement ?

Il permet le parcours de tableaux de structure ou d'accès en stride où on n'a besoin que d’une case sur 2,3, 4, 5, …

Tu pourrais donner un exemple de structure d'un point de vue programmation. A l'origine, je croyais que tu parlais des dictionnaires.

C'est les structures du C. Encore une fois, cette partie du cours a un lien assez fort avec les langages de programmation de bas-niveau : il faut savoir que ces modes d'adressage ont ététs inventés pour favoriser les manipulations sur les tableaux et structures du C ou d'autres langages de programmation. Ce chapitre et le suivant sont assez fortement lié à la programmation, et des connaissances en programmation en C/C++ aident vachement.

Les schémas aident globalement à comprendre, mais des exemples concrets seraient je pense plus explicites : je suis dans tel mode d'adressage, j'envoie telle instruction, que se passe-t-il pas-à-pas ? Après, il faut savoir que j'aime beaucoup les cas de figure pour illustrer les propos, donc mon conseil est probablement biaisé.

Les cas de figure en question demanderaient d'ajouter beaucoup d'ASM dans le cours, ce qui serait clairement overkill.

+0 -0
Ce sujet est verrouillé.