Fonctionnement des ordinateurs de zéro

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

Très bêtement : je me suis dit que le 610 contenu dans le registre était le même que celui de la case mémoire 1001, c'est-à-dire le contenu de cette case, et non une adresse. Mon raisonnement est incorrect, mais le schéma prête à confusion.

C'est les structures du C.

J'imagine, mais je connais très peu le C.

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

Et un ASM simplifié, comme dans mon message, ça ne conviendrait pas ?

Bonjour, je lis ce cours que je trouve très intéressants et je suis un débutant dans le domaine de l'architecture des ordinateurs. J'en suis au chapitre 3 de la partie 2 (contrôleur mémoire interne) et je me demande dans quels types de ram sont utilisés les mémoires par blocs et coïncidences ? La SRAM, SDRAM asynchrones, SDRAM asynchrones utilisent les mémoires par blocs ou coincidences ou row buffer ?

Pour les SRAM, ca dépend. Pour les SDRAM et autres, c'est expliqué dans les chapitres suivants.

Jeux d'instruction

Cette complexité des jeux d'instructions a aussi quelques avantages techniques

Je ne comprends pas le "aussi".

diminuant la code density

Est-on censé connaître la notion de code density ?

Load-store

Est-on censé connaître ce terme ? En parles-tu dans la deuxième partie, sur la mémoire ?

chacun a des avantages et des inconvénients, qui rendent le RISC/CISC adapté ou pas selon la situation.

J'imagine qu'il n'est pas facile de donner des listes des situations adaptées au RISC et de celles adaptées au CISC ?

Sur les machines à pile, les données que le processeur manipule sont regroupées dans une pile.

Qu'entends-tu par "données" ? Des instructions ? Des opcodes ? Des opérandes ? En fait, je ne comprends pas trop ce qu'on est en train de faire.

Vu qu'une instruction consomme ses opérandes, on ne peut pas les réutiliser.

Je ne comprends pas trop ce que tu entends par là.

On peut aussi citer l'instruction swap, qui échange deux données dans la pile.

Un exemple d'utilisation ?

Image de Poil sous licence CC BY-SA 3.0 et GFDL 1,2, disponible sur wikicommons

Je ne comprends pas ce schéma. "SP" signifie "Sommet de Pile" ? Que représente la pile du bas ?

Les machine à pile que je viens de décrire ne peuvent manipuler que des données sur la pile : ces machines à pile sont ce qu'on appelle des machines zéro adresse.

Toutefois, certaines machines à pile plus évoluées autorisent certaines instructions à préciser l'adresse mémoire d'une (voire plusieurs dans certains cas) de leurs opérandes. Ces machines sont appelées des machines à pile une adresse.

Je n'avais pas compris la première partie avant de lire la seconde.

Load-store

Le schéma me paraît bizarre : ne devrait-on pas avoir une flèche vers la RAM, pour store ?

On appelle ces processeurs, conçus pour des besoins particuliers, des processeurs dédiés.

Tu pourrais parler du terme "Appliance", qui apparaît dans le titre. Actuellement, on ne le comprend pas tellement.

Mais de nos jours, cela tend à disparaitre, et les processeurs ne disposent plus d'instructions de ce genre.

[…]

De nos jours, ces processeurs n'existent plus que dans quelques muséums : ils ont faits leur temps, laissons-les reposer en paix.

Pourrais-tu expliquer brièvement pourquoi ?

Je n'ai pas très bien compris ce qu'est un jeu d'instructions. Au départ, tu dis que c'est simplement une description des instructions possibles et de leur syntaxe, mais après tu parles d'implémentation (pile, accumulateur, etc.). Du coup, j'ai un peu de mal à prendre du recul par rapport à ça.

Merci.

Alignement et Endianess

Quand on veut lire ou écrire une donnée sur un bus plus grand que celle-ci, les Bytes en trop sont copiés sur le bus, mais le processeur les ignore.

Je ne suis pas sûr de comprendre cela, ni le schéma qui suit d'ailleurs.

Avec alignement, la mémoire peut être vue comme une mémoire de capacité équivalente, dont chaque Byte a la taille d'un mot.

Peut-être est-ce parce que je n'ai pas lu la partie sur la mémoire, mais je ne comprends pas ce que tu entends par "mémoire de capacité équivalente". En fait, je ne comprends pas le terme "capacité", ni comment on peut avoir le terme "équivalente" non suivi de "à".

Par exemple, si on prend un groupe de deux octets, on est certain qu'une case sur deux sera inutile : les adresses impairs pointeront sur l'octet de poids fort de notre groupe.

J'ai bloqué sur l'expression "une case sur deux sera inutile", puisqu'on utilise toutes les cases pour stocker des données, donc aucune n'est inutile. Veux-tu dire par là que ç'aurait été pareil si on avait eu deux fois moins de cases, mais chacune de taille double ?

Dans la réalité, ces blocs ont une taille égale à une puissance de deux : on peut obtenir l'adresse d'un mot à partir de l'adresse normale, en mettant à zéro certains bits de poids faible.

J'ai un peu de mal sur ce passage.

Pour éviter ce genre de choses, les compilateurs utilisés pour des langages de haut niveau préfèrent rajouter des données inutiles (on dit aussi du padding) de façon à ce que chaque donnée soit bien alignée sur le bon nombre d'octets.

Comment fais-je si une donnée est de taille strictement supérieure à celle du bus ? Pour reprendre ton exemple, si je code mon entier sur 5 octets.

Certains processeurs sont un peu plus souples : ils laissent le choix de l'endianness, et permettent de le configurer de façon logicielle ou matérielle. Ces processeurs sont dits Bi-endian.

Comment renseigne-t-on le mode choisi ? On le stocke avec la donnée, un peu à la manière d'un mode d'adressage ?

Certains processeurs sont toutefois un peu plus sadiques : ils utilisent des bytes de plusieurs octets. Dans ce cas, il faut aussi prendre en compte l'endianess des octets dans le byte, qui peut être big-endian ou little-endian.

Pourquoi ne renseigne-t-on pas un endianess par byte, plutôt que par octet ? Pour reprendre l'analogie linguistique, je lis pas un coup une phrase de gauche à droite et une autre fois dans le sens inverse : le sens de lecture est propre au texte (le byte) et non aux phrases (les octets).

Pfiou, j'ai terminé cette section, et donc ce chapitre. Peut-être pourrais-tu ajouter un résumé des idées principales (registres, instructions, opcode, mode d'adressage, jeu d'instructions, alignement et endianess) en conclusion ?

Merci.

Oyez oyez les agrumes !

Je vous annonce avec plaisir la ré-ouverture de la bêta du contenu « Fonctionnement des ordinateurs de zéro » ! Je vous souhaite une agréable lecture à l'adresse suivante :

Merci pour votre participation.

Très bon boulot , c'est vraiment un article de bonne qualité et assez rare que je donnerai en lien volontiers a de nombreux débutant qui demande souvent comment commencé en assembleur. Je regrette juste que tu n'a pas parlé du NMI dans la partie Communication avec les Entrées-Sorties/Interruptions.

Des simplifications dans le chapitre sur les ALU entières et flottantes. Une partie des explications a été simplifiée et légèrement revue.

Merci d'avance pour vos commentaires.

Comme le souligne Kannagi, il y a de fortes chances qu'on lise ce tutoriel pour se mettre à l'assembleur. Sachant cela, ne serait-il pas judicieux d'inverser les deuxième et troisième parties ?

Au passage, je souhaiterais réagir à un message que tu avais écrit plus haut, disant que les lecteurs s'arrêtaient aux premières parties (du moins, que tu n'avais pas eu de retour sur les suivantes). Je me demande si ce n'est pas lié au fait que ton tutoriel est uniquement théorique. J'ai personnellement beaucoup de peine à retenir des notions que je n'ai pas utilisées, manipulées. Donc non seulement j'oublie les choses d'un chapitre sur l'autre, mais je sais qu'à la fin, j'aurai oublié la majeure partie des connaissances acquises.

Après, si je puis me permettre mon grain de sel, attaquer l’assembleur par l’étude du matériel, c’est un peu comme faire l’ascension d’un sommet par la face Nord au cœur de l’hiver et en tongs…

Certains passages de la troisième partie réutilisent des notions vues dans les premiers chapitres de la seconde partie. Je ne peux donc pas inverser les deux tant que ces pré-requis internes sont là. Et pour quelqu'un qui souhaite apprendre l'assembleur, ce cours est relativement peu adapté pour une raison simple : toute la première partie est totalement overkill pour quelqu'un qui a ce but.

En même temps, c'est très difficile de manipuler quoique ce soit dans ce domaine sans un niveau d'expertise assez élevé.

Demander au lecteur de concevoir quelques circuits relativement simples serait un bon début, mais ne permettrait que de consolider les acquis des premiers chapitres de la première partie. Faire concevoir un processeur ou une mémoire par le lecteur (totalement ou en partie) serait long, frustrant et demanderait d'utiliser un FPGA ou quelque chose du genre. Je pourrais éventuellement faire travailler le lecteur sur des FPGA, ce qui demanderait de voir le VHDL ou le verilog et d'autres connaissances totalement hors-sujet vis à vis du sujet du cours (ça et le prix d'un FPGA me font penser que c'est une mauvaise idée). Rajouter de la programmation système ou matérielle très bas-niveau augmenterait les pré-requis du cours d'une manière qui serait nuisible au cours.

J'avais bien pensé à ajouter des exercices ou des TD/TP dans le cours, mais sincèrement je n'ai pas trouvé grand chose. J'avais notamment pensé à des TD du style "Concevez votre propre ISA" (avec des contraintes soit sur la code density, ou autre), mais ce serait clairement overkill. Mais clairement, ce n'est pas pour tout de suite. C'est encore à l'état d'idée, et les mettre en oeuvre sera long et fastidieux. Pour une prochaine version du cours au mieux, jamais dans le cas le plus probable.

Même si l'introduction de pratique dans ton cours n'est pas pour tout de suite, j'ai une idée qui pourrait t'intéresser pour la partie "Processeur et Assembleur". En cours d'architecture des ordinateurs, j'ai fait un gros TP de simulation d'un CPU simplifié. On utilisait un logiciel gratuit, un genre de petit simulateur d'électronique numérique, avec une bibliothèque de composants.

Le TP consistait à assembler les composants (mémoires, ALU, registre d'instruction, séquenceur, etc.) pour avoir la bonne archi, puis réaliser le séquenceur (combinatoire je crois) pour exécuter différentes instructions (ADD, JMP, STORE, etc.). Le point culminant du TP était l'exécution d'un code dans l'assembleur du CPU simplifié, puis la programmation de la multiplication à partir de l'addition. C'était assez gratifiant quand tout fonctionnait à la fin. Les étudiants n'avait aucune notion d'architecture des ordinateurs, mais connaissaient l'électronique numérique et savaient à peu près programmer avant le cours.

J'ai aucun souvenir précis de ce cours à part ça. Pourtant, on a vu beaucoup des choses dont tu parles, sur les modes d'adressages, les trucs synchrones ou pas, les bus, ou le Direct Memory Access. Du coup, je pense que ça peut être un bon truc pour faire rentrer les concepts.

Je note pour l'utilisation de simulateurs d'architecture d'ordinateur - CPU Sim à l'air pas mal, d'ailleurs. Le simulateur SimpleScalar me serait aussi utile pour les dernières parties : il permet de simuler de vrais CPU superscalaires OOO . L'idée de faire des TP sur CACTI, un outil de simulation de mémoire cache m'avait aussi traversé l'esprit. Reste à voir si ces outils sont faciles à utiliser, vu qu'il s'agit d'outils destinés à la base pour la recherche… De mémoire, CACTI était assez simple à utiliser, mais je ne sais pas pour les autres.

J'avais aussi pensé à la programmation d'un émulateur, mais cela risque d'être assez peu relié à l'architecture d'un ordinateur.

Demander au lecteur de concevoir quelques circuits relativement simples serait un bon début, mais ne permettrait que de consolider les acquis des premiers chapitres de la première partie.

Dans la mesure où je n'ai lu que la première partie et un chapitre des deux suivantes, je pensais surtout à ce type d'exercices. Ayant commencé l'archi en septembre, je me souviens n'avoir vraiment compris les concepts de bascule et d'horloge (entre autres) qu'en créant des registres et dessinant des chronogrammes.

Sinon, un truc qu'on a beaucoup fait, c'est l'architecture PC/PO. Concrètement, on partait d'un algorithme (par exemple, calcul de PGCD), on listait les composants à utiliser (notamment le nombre d'UAL, avec ou sans parallélisation des opérations), on construisait la PO, puis un automate pour la PC et "implémentait" cet automate, avec un codage un parmi n ou logarithmique.

Au menu : de nombreuses améliorations et simplifications d'explications, ainsi que des refontes du plan dans les chapitres sur le disque dur, la carte son, le pipeline, les architectures découplées et les architectures fonctionnelles.

Merci d'avance pour vos commentaires.

Je reste assez d'accord dans le sens ou un pur débutant devrait commencer par un langage plus évolué et encore moins regardé comment fonctionne l’électronique, mais faire de l'assembleur sans aucune base théorique reste du bidouillage au mieux , Si un débutant tombe sur le IRQ ,le DMA en assembleur sans connaissance théorique cela restera flou pour lui , de même que un cours qui explique le binaire/décimal , les nombres positif/negatif ,la mémoire ect

Après certaines partie peut être 'ignoré' si on veut seulement faire de l'asm , mais a ma connaissance c'est le seul tuto qui parle de tout ceci.

Même si l'introduction de pratique dans ton cours n'est pas pour tout de suite, j'ai une idée qui pourrait t'intéresser pour la partie "Processeur et Assembleur".

Je précise que je suis pour que le tuto reste a l'état , cela veut dire que c'est un cours qui est un complément de la pratique .

Sinon pour ma part cela reste un long débat , quel assembleur choisir ?

Le X86 je le trouve trop complexe a l'heure actuel de plus son intérêt reste moindre sur un PC dans le sens ou il faudra passé par des fonctions écrite plus souvent en C pour communiquer avec la matériel…

Sinon pour les autres assembleurs récent on a l'ARM , le pic et AtMega sont bien et reste une bon choix pour commencer a mon avis.

Pour les processeurs plus anciens on a le 6502 , 68000 et le Z80 , j'ai une préférence pour le 6502 c'est un processeur très simple donc de mon point de vue plus prompt a être enseigner.

J'avais eu l'idée aussi de faire un tuto de l'assembleur avec comme émulateur une master system (ou pour les plus retro d'entre nous sur du vrai Hard) , je trouve la master system très facile a programmer avec un cpu en z80 , tout en restant ludique.

Je dirait que la Nes peut suffire aussi mais je suis pas un fan de l'architecture Made in Nintendo Pour le reste des vielles consoles la SNES est un vrai parpaing , la Megadrive c'est du 68000 de même que la Neo Geo et le reste des bornes d'arcade fin 80-debut 90.

Bref je pense que c'est intéressant de faire l'asm et de pouvoir tester sur du vrai Hard , le x86 grâce au PC est le plus prompt a remplir ces conditions mais comme je l'ai dit avant le x86 moderne + OS , l’intérêt devient vite inutile.

Je reste assez d'accord dans le sens ou un pur débutant devrait commencer par un langage plus évolué et encore moins regardé comment fonctionne l’électronique, mais faire de l'assembleur sans aucune base théorique reste du bidouillage au mieux

Non, pas vraiment. C’est juste que tous les tutos d’assembleur x86 commencent par le mode réel qui oblige à se fritter dès le départ avec plein d’aspects chiants liés au matériel. Mais si tu prends le contre-pied en commençant par du x86_64 intégré à un OS avec tous les syscall et tout (je l’ai déjà fait), c’est beaucoup plus simple à aborder, et surtout, tu peux te permettre d’ignorer l’essentiel du fonctionnement de la bête pendant une bonne partie de l’apprentissage.

Le X86 je le trouve trop complexe a l'heure actuel de plus son intérêt reste moindre sur un PC dans le sens ou il faudra passé par des fonctions écrite plus souvent en C pour communiquer avec la matériel…

Pas vraiment non plus. En tous cas, sous un Unixoïde, les syscalls sont là pour communiquer avec « le matériel » sans faire appel à des fonctions C.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l'adresse suivante :

Merci d'avance pour vos commentaires.

Bonjour à tous !

J'ai du mal à comprendre ce schéma-ci :

En fait, l'entrée D est directement reliée aux transistors M3 et M4, qui vont inverser le bit, et directement après on trouve la sortie Q. Donc mettre 1 en entrée D (donc enregistrer un 1) sortira un 0 en sortie Q ??

Sauf que c'est l'inverse du bit à mémoriser qui est envoyé sur l'entrée D. Du moins, c'est ainsi que c'est fait avec des bitlines différentielles. Le tout est censé être expliqué dans les chapitres suivants, mais ajouter une remarque à ce propos dans le chapitre sur les SRAM/DRAM ne serait pas du luxe.