Discussion :

[AxAx_]

Bonjour,

Voilà, j'intitule ce post architecture système car cette question portant sur les registres est très certainement la première d'une longue série.

J'essaie de parfaire mes connaissances avant d'entrer en première année de licence.
Le livre est intitulé «*Introduction aux systèmes informatiques*» aux éditions DUNOD.

Ma première question porte sur les registres, la compréhension de ce que c'est.
Le livre ne suffisant pas, j'essaie de croiser de l'information glanées sur le web et essaie de créer un truc plus ou moins tangible mais je commence à sérieusement m'y perdre plus j'en lis.

J'ai donc compris qu'il y avait une hiérarchisation des systèmes de stockages et que le registre était au top de la pyramide en terme de vitesse ce qui visiblement est inversement proportionnel à sa capacité sur un système comparé aux autres unités de stockages pour des raisons de coût.

En gros, plus le système de stockage est rapide, plus il coûte cher et donc moins on en met.

Mon problème est que «*les registres*» sont considérés comme des emplacements mémoires dans le processeur.

Donc sommes-nous d'accord que ces registres ne se trouvent pas dans la mémoire centrale*?
Sommes-nous d'accord qu'ils sont bien «*physiquement*» sous forme de matériel dans le processeur*?

Parce que je trouve ça bizarre et ça me donne l'impression de mélanger un peu tout.

On dit que la capacité d'un registre équivaut au mot mémoire du processeur.
Donc là encore, je suppose qu'un mot mémoire sur une machine comme la mienne composé d'un i7 avec un windows 10 64bits installé dessus doit sûrement manipuler des mots mémoire de «*64bit*».


J'ai l'impression de comprendre également qu'un mot mémoire, c'est une succession de cellules qui contiennent chacune 1bit (dans laquelle se trouve un 0 ou un 1 je présume) et que l'ensemble de ces 64bits forment mon mot mémoire et donc le contenant d'un registre*?

Ensuite, on me parle de*:
registres généraux interchangeables,
registres spécialisés.

Certains sont liés à la mémoire centrale et d'autres à l'unité de contrôle donc c'est là que je commence à me perdre et à me demander si le registre est un «*concept*» abstrait ou une unité de stockage physique comme une barrette de RAM par exemple...

Je trouve que cela contredit la première phrase du livre qui me disait qu'un registre, c'est un emplacement de mémoire interne à un processeur puisque je pense, peut être à tord, que la mémoire centrale et le processeur sont deux endroits différents*?!

Donc si quelqu'un peut me dire ce que sont les registres et si on les voit physiquement quelque part.
Ça m’intéresse.

Je crois comprendre aussi que le contenu de ces registres est volatile*? Mais qu'en est-il de la «*base des registres*» de windows qu'on accède via «*regedit*»*? J'ai l'impression que ça contient également des «*clés*» de données persistantes comme des programmes installés sur mon ordinateur*? Est-ce un truc complètement différent*?

Et dernière chose, la RAM.
Elle est bien connectée au Bus d'adresse qui lui même est connecté au processeur*?
Qu'est ce qui transite entre le processeur et la RAM via le bus d'adresse*? L'adresse des registres*? Qui elle même contient le mot mémoire contenu dans le registre et qui sera stocké dans la mémoire centrale après son passage dans le décodeur*?

Et du coup, un mot mémoire dans la mémoire centrale, ça s'appelle comment*? Toujours un registre*?


Voilà merci pour votre aide et désolé je pense que je mélange un peu tout et ça risque d'en énerver quelque uns*donc merci pour votre patience.

[foetus]

Les registres sont des emplacements pour permettre au processeur de travailler.
Par exemple pour faire l'addition de 2 entiers, il faudra charger au préalable 2 registres prédéfinis pour que le processeur puisse faire l'addition.

Ensuite on parle des processeurs x86, et donc 1 processeur hybride RISC/ CISC.
Pour 1 processeur RISC (comme le PowerPC d'IBM) si tu as 1 processeur de X bits, tu as X registres (<- à vérifier quand même)

Par conséquent, les registres x86 c'est 1 peu le chantier :

• la taille des registres correspond à la taille processeur. C'est pour cela que AH/ AL sont des registres 8 bits, AX (qui englobe AH et AL) est 16 bits, EAX (englobe AX, E pour Extended) 32 bits et maintenant RAX 64 bits (englobe EAX). À chaque évolution, les registres évoluent en concordance.
• pareil, au départ tu avais 4 registres généraux en 16 bits (AX, BX, CX, DX) Mais en 32 et 64 bits cela a évolué pour arriver à 16. Les registres généraux sont les registres qui vont contenir les valeurs pour que le processeur puisse travailler
• les registres spécialisés (*) sont (registres d'offset) SI (adresse source pour déplacement ou comparaison)/ DI (adresse destination pour déplacement ou comparaison)/ SP (pointeur de pile (stack pointer))/ BP (pointeur de base (base pointer)) + IP (instruction pointeur) + (registres de segment) CS/ DS/ SS/ ES + FS/ GS (<- qui ont dû apparaître en 32 ou 64 bits)

* Si 1 registre commence par E il est 32 bits (ESI, EAX), commence par R il est 64 bits (RSI, RAX). En 16 bits, il y avait les poids forts (H) et les poids faibles (L) (AL/ AH, BL/ BH)

Édit : les registres d'offset semblent être des registres généraux, pour tous les calculs d'adresses (avec la pagination)

Donc après tu vois bien que si tu fais 2 additions, les registres vont avoir des valeurs qui vont changer d'1 opération à l'autre. Donc oui, c'est *volatile*.
Pour la mémoire, c'est normal. Si tu prends 1 addition, tu peux additionner 1 valeur à 1 variable. La valeur de la variable est stockée en mémoire (cache ou centrale) et il faudra aller la chercher.
Et le bus mémoire depuis le 32 bits est toujours également à la taille processeur.

À vérifier et viens me corriger, il n'y a pas de problème

[Kannagi]

Ma première question porte sur les registres, la compréhension de ce que c'est.

Il faut faire attention parce que le mot registre peut être très généraliste comme terme vu que tu fais cette erreur :

Mais qu'en est-il de la «*base des registres*» de windows qu'on accède via «*regedit*»*? J'ai l'impression que ça contient également des «*clés*» de données persistantes comme des programmes installés sur mon ordinateur*? Est-ce un truc complètement différent*?

Celà n'a rien n'a voir avec les registre windows.

Mais on utilise aussi des fois le mot registre pour les I/O

Sur ton livre , il parle des registres du processeur.

Mon problème est que «*les registres*» sont considérés comme des emplacements mémoires dans le processeur.

Donc sommes-nous d'accord que ces registres ne se trouvent pas dans la mémoire centrale*?
Sommes-nous d'accord qu'ils sont bien «*physiquement*» sous forme de matériel dans le processeur*?

Parce que je trouve ça bizarre et ça me donne l'impression de mélanger un peu tout.

Les registre sont directement dans le processeur ,et elle est aussi de nature différente.
Les registres processeurs c'est de la SRAM donc de la RAM avec des transistors ( il faut 4/6 transistor pour faire 1 bits) , la RAM est généralement de la DRAM , c'est de la mémoire avec des condensateurs (en général 1 transistor + 1 condensateur) , ça prend beaucoup moins de place , mais c'est plus lent ,vu qu'un condensateur à un temps de charge/décharge assez long comparait à la vitesse du proc.

De plus , comme c'est des condensateurs , il se décharge avec le temps ( et sur la DRAM , elle se décharge en quelque ms ) , du coup les DRAM sont rafraîchit périodiquement pour ne pas perdre leur donnés (ce qui du coup ralentit aussi la vitesse de ce type de RAM , vu qu'elle sont indisponible pendant un court laps de temps ).

On dit que la capacité d'un registre équivaut au mot mémoire du processeur.
Donc là encore, je suppose qu'un mot mémoire sur une machine comme la mienne composé d'un i7 avec un windows 10 64bits installé dessus doit sûrement manipuler des mots mémoire de «*64bit*».

J'ai l'impression de comprendre également qu'un mot mémoire, c'est une succession de cellules qui contiennent chacune 1bit (dans laquelle se trouve un 0 ou un 1 je présume) et que l'ensemble de ces 64bits forment mon mot mémoire et donc le contenant d'un registre*?

En général on considère qu'un processeurs 64 bits = mot mémoire de 64 bits.
Mais vraiment , tu peux "oublier" cette histoire de mot mémoire , il y'a tellement de processeur (et exotique en plus) que tu peux trouver des procs qui sont 8/16 bits ou 16/32 bits
Ou même le x86 qui va posséder des registres de 64/128/256 bits
Par convention on considère que c'est un proc 64 bits parce que l'ALU travaille avec du 64 bits.
Mais là aussi dire que c'est un 64/128/256 bits serait pas totalement faux ,vu qu'il peut gérer des registres de ces différentes tailles.

Ensuite, on me parle de*:
registres généraux interchangeables,
registres spécialisés.

Certains sont liés à la mémoire centrale et d'autres à l'unité de contrôle donc c'est là que je commence à me perdre et à me demander si le registre est un «*concept*» abstrait ou une unité de stockage physique comme une barrette de RAM par exemple...

Je trouve que cela contredit la première phrase du livre qui me disait qu'un registre, c'est un emplacement de mémoire interne à un processeur puisque je pense, peut être à tord, que la mémoire centrale et le processeur sont deux endroits différents*?!

Donc si quelqu'un peut me dire ce que sont les registres et si on les voit physiquement qq part.
Ça m’intéresse.

Disons que de nos jours on ne fait que des registres interchangeable , appelé registre généraux.
Les registres spécialisé dans le passé existé que pour une raison : le nombre de transistor était limité , on devait faire des processeurs avec 10000 transistor ou moins (comparé à maintenant avec un Apple M1 et ces 15 milliards de transistors ).
L'autre raison était que tout les processeur était CISC ce qui rendait le circuit relativement complexe et les faire généraliste serait encore plus problématique , (pour cela que les registre généraux soit venu avec les procs RISC entre autre ).

Alors il faut savoir que le x86 avait des registres spécialisé pour des raisons historiques ,mais tous peuvent se comporter comme des registre généraux.
Il y'a quand même des processeurs "moderne" avec des registres spécifiques pour des raisons "d’optimisation" , mais je n'en dira pas plus parce que c'est relativement complexe à comprendre

Donc oui ,c'est bien un concept réel , et tu peux les voir physiquement et les manipuler en programmation assembleur :
par exemple tu peux faire un truc comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
move r0,r1

Qui copie le registre 1 dans le registre 0

Et dernière chose, la RAM.
Elle est bien connectée au Bus d'adresse qui lui même est connecté au processeur*?
Qu'est ce qui transite entre le processeur et la RAM via le bus d'adresse*? L'adresse des registres*? Qui elle même contient le mot mémoire contenu dans le registre et qui sera stocké dans la mémoire centrale après son passage dans le décodeur*?

Et du coup, un mot mémoire dans la mémoire centrale, ça s'appelle comment*? Tjs un registre*?

Alors ça ne marche pas comme ça.
Pour écrire lire en RAM , il faut l'adresse plus les data.
Mais quasiment aucun processeur n'écrit directement sur la RAM (sauf dans l'embarqué) , vu qu’elle est plus lente, et donc non suivant le type de RAM on va écrire un bloc de mémoire , les GDDR (les RAM de processeur graphique ) peut écrire jusqu'a 32/64 octets par cycle, les DDR sont variable et tu trouvera du 4 à 16 octets par cycle.

Pour de l'embarqué ou des vieux proc , la tout dépend du bus de données et donc tu pouvais avoir des procs 16 bits qui avait un bus de données de 8 bits , comme le 8088 (un dérivé du 8086 mais en 8 bits de bus) , la raison était économique pour l'époque
Mais ce n'est pas le seul qui avait des registres plus gros que le bus de données ,et c'est normal

Et je pense que tu mélange un peu tout les terme
"le processeur et la RAM via le bus d'adresse*? L'adresse des registres*?" ben non une adresse, qui est donné soit par un registre (spécialisé ou pas ), soit peut être donné par des pointeurs en RAM (comme le 6502).
"Qui elle même contient le mot mémoire contenu dans le registre et qui sera stocké dans la mémoire centrale après son passage dans le décodeur*?" ça , ça ne veut rien dire
"Et du coup, un mot mémoire dans la mémoire centrale, ça s'appelle comment*? Tjs un registre*? " , y'a pas de noms pour dire que des condensateur soit chargé ou pas ,tu stokes de l’information point barre , la RAM c'est comme un tableau , tu lis/écrit ce que tu veux dedans , c'est juste ordonné par case.


Après je n'ai pas lu ton livre , mais j'ai l'impression qu'il parle d un peu des processeurs des années 80 , faut plus comme son nom l'indique une introduction avec des informations pas forcément très "utile" ou juste , en tout cas pour le mot mémoire vu que bon ça reste un sujet débat que je vois souvent (vu que ben tu as des processeurs qui sont à cheval entre deux taille bonne question pour les caser quelque part).

[AxAx_]

Merci pour vos réponses.

Je crois que ma grosse erreur a été d'associer cette base des registres d'entrée de jeu à ces registres et ça a parasité un peu l'intégration du concept à prendre comme tel car je n'arrivais pas à lier les deux.
Le fait que ça n'ait rien à voir change vraiment la donne dans ma compréhension.


Donc effectivement, la mémoire centrale (DRAM) et entre les deux (processeur et DRAM) il y a la mémoire cache (SRAM) qui semble acquérir de la donnée par bloc depuis la mémoire centrale.
Par contre, évidemment, le cache envoie par mot au processeur et j'ai cru comprendre qu'il y avait jusqu'à 3niveaux de cache avec des perfs différentes directement proportionnelles à leur proximité avec le processeur, ce qui semble assez logique.


Sinon, tu dis qu'on ne parle plus de "mot" ?
C'est parce qu'on alloue de la mémoire virtuelle lorsque les 2^n cellules ne suffisent pas que ça fausse un peu la rigidité qui pourrait découler du mot "mot mémoire" de n bits ?


Oui du coup, j'avais bien noté aussi cette histoire de 4à6transistors sur la SRAM, je n'ai juste pas encore bien réussi à m'approprier le concept de la bascule de Type D.
Par contre, pour la DRAM, j'avais bien compris le refresh toutes les x ms à cause du courant de fuite des condensateurs, ça c'est ok et également pour les histoires de bits de contrôle.



Et oui du coup, j'ai compris aussi que c'est un compliqué de faire une phrase où on ne parle que du Bus d'adresse puisque les deux Bus d'adresses/bus de données sont liés.
Si on lit une info, je charge dans le registre RAM, une adresse, je lance la commande R/W = 1 et l'information est disponible dans les registre RIM ou RDM après un laps de temps et pour l'écriture là c'est on me prépare une adresse dans lequel on va écrire ce que j'aurai passé via le RDM et un r/w = 0


Ben écoutes, le livre semble avoir connu son dépôt légal en 2017 après, est-ce que c'est une réédition, je n'en sais rien...
Je viens de survoler les IAAS, SAAS, PAAS donc je pense pas qu'on parlait de ça dans les années 80 ni de cloud même si c'est plus tout récent non plus.
Par contre, là j'avoue que j'ai clôturé le chapitre du stockage sur les sauvegardes sur bande magnétique et là effectivement, le backup cassette, ça doit plus forcément être aussi systématique que dans les années 90.
Surement pour des raisons de coûts de support.

Là, je vais enchainer sur le processeur, ça éclaircira surement les concepts sur la mémoire tout en donnant naissances à de nouvelles questions !
Si jamais vous pensez avoir une bibliographie "abordable" intellectuellement, n'hésitez pas ou des ressources fiables sur internet.
J'avoue que je perds beaucoup de temps à chercher sur internet, j'aime les livres même si ça a un coût, j'ai l'impression que je le retrouve en temps.

Merci pour l'aide en tout cas.

[Kannagi]

Effectivement ce que tu dis là , semble plus cohérent.

Donc effectivement, la mémoire centrale (DRAM) et entre les deux (processeur et DRAM) il y a la mémoire cache (SRAM) qui semble acquérir de la donnée par bloc depuis la mémoire centrale.
Par contre, évidemment, le cache envoie par mot au processeur et j'ai cru comprendre qu'il y avait jusqu'à 3niveaux de cache avec des perfs différentes directement proportionnelles à leur proximité avec le processeur, ce qui semble assez logique.

J'ai vraiment du mal avec le français technique je pense , j'avais pas compris "mémoire centrale"
Donc oui tu as le processeur -> cache -> memory controlleur -> DRAM.

La mémoire cache envoie "un mot" , oui , enfin il peut en envoyer même plusieurs en même temps , c'est un peu plus compliqué , un silicium c'est gravé sur du marbre , donc tu te base souvent sur la taille la plus grosse

Alors les 3 caches , pas forcément tu peux en avoir le nombre que tu veux.

Apple M1 n'a que 2 niveau de cache et le AMD ryzen n'a que 3 niveau de cache ,et les GPU ont en souvent 4-5.
Et y'a pas de stratégie mieux qu'une autre , il faut savoir que plus le cache L3 est gros , plus il ralentit le cache L2 et plus il ralentit le cache L1.
Donc faire 3 niveau de cache ,c'est un choix , Apple n'a sûrement pas trouvé ce choix plus judicieux apparemment

Sinon, tu dis qu'on ne parle plus de "mot" ?
C'est parce qu'on alloue de la mémoire virtuelle lorsque les 2^n cellules ne suffisent pas que ça fausse un peu la rigidité qui pourrait découler du mot "mot mémoire" de n bits ?

Je fais un CPU , et je me suis jamais posé la question.
Ce n'est pas la question , c'est juste que c'est une vision un peu rigide de voir un processeur , c'est plus complexe et on gère différente taille suivant le contexte
Et là aussi tu te mélange , la mémoire virtuel c'est autre chose, c'est surtout fait pour les OS , qui font exécuter les programmes dans une mémoire virtuel pour des raisons de sécurité entre autre.
Mais apres ,c'est peut être le terme français que je confond un peu avec un autre.

Je lis le coté wikipedia ,et donc même si "mot mémoire " , y'a mémoire dedans , ça n'a rien n'a voir avec le cache ou la RAM
Techniquement , c'est la taille des registres pour les "entiers" , et on ne se cale plus dessus pour le bus mémoire ou autre (mais c'était le cas avant dans les années 80 , mais c'est normal le processeur communiquait directement avec la RAM ).

Mais je t'ai pourtant donné un exemple même à l'époque tu pouvais avoir une dif entre les deux :

et donc tu pouvais avoir des procs 16 bits qui avait un bus de données de 8 bits , comme le 8088 (un dérivé du 8086 mais en 8 bits de bus) , la raison était économique pour l'époque

Je vais prendre un exemple ou le "mot mémoire" n'a rien n'a voir avec la RAM ou le bus.
Tu prend la Super nintendo, c'est un processeurs 16 bits (donc par logique mot mémoire de 16 bits), le bus de données était de 8bits , et le bus d'adresses de 24 bits !

Mais la aussi même le cache n'est pas sur un bus 64 bits , sur le x86 (Intel ou AMD) ,le cache L1 est sur un bus de 256/512 bits

Et oui du coup, j'ai compris aussi que c'est un compliqué de faire une phrase où on ne parle que du Bus d'adresse puisque les deux Bus d'adresses/bus de données sont liés.

Exactement , y'a peu d’intérêt d'envoyer que de l'adresse

Là, je vais enchainer sur le processeur, ça éclaircira surement les concepts sur la mémoire tout en donnant naissances à de nouvelles questions !
Si jamais vous pensez avoir une bibliographie "abordable" intellectuellement, n'hésitez pas ou des ressources fiables sur internet.
J'avoue que je perds bcp de temps à chercher sur internet, j'aime les livres même si ça a un coût, j'ai l'impression que je le retrouve en temps.

J'ai appris toute la micro architecture sur le net , jamais lu un bouquin dessus
Si tu veux un bouquin je te conseil "Computer Architecture A Quantitative Approach " ,c'est le seul que je connais qui est poussé sur la micro architecture (le bouquin fait plus de 1400 pages) , tu peux trouver la version PDF aussi.

Par contre ça serait pas mal de pratiquer ce que tu lis , parce que ta réflexion précédente " les registres sont -t-il des choses concrète" , peut étonner un programmeur bas niveau , vu que les registres , tu en manipule très très souvent en assembleur

[AxAx_]

Mais je t'ai pourtant donné un exemple même à l'époque tu pouvais avoir une dif entre les deux :


Mais la aussi même le cache n'est pas sur un bus 64 bits , sur le x86 (Intel ou AMD) ,le cache L1 est sur un bus de 256/512 bits


Exactement , y'a peu d’intérêt d'envoyer que de l'adresse


J'ai appris toute la micro architecture sur le net , jamais lu un bouquin dessus
Si tu veux un bouquin je te conseil "Computer Architecture A Quantitative Approach " ,c'est le seul que je connais qui est poussé sur la micro architecture (le bouquin fait plus de 1400 pages) , tu peux trouver la version PDF aussi.

Par contre ça serait pas mal de pratiquer ce que tu lis , parce que ta réflexion précédente " les registres sont -t-il des choses concrète" , peut étonner un programmeur bas niveau , vu que les registres , tu en manipule très très souvent en assembleur

Oui j'ai bien lu ton exemple mais je ne comprends pas trop l'intérêt de ce choix technique (économique tu me diras).
Si tu as un processeur de 16bits et un bus de 8bits, j'ai l'impression que ça force le processeur à travailler "lentement" quelque part en donnant moins que ce qu'il est capable de prendre.
Idem à l'inverse, ton procs de 64bits à qui on envoie 256bits, j'ai un peu du mal à voir comment il gère ça mais j'y verrai sans doute plus clair quand j'aurai commencé et fini le chapitre sur le processeur.

Du coup, c'est pour ça que j'en suis venu sur la mémoire virtuelle, car en effet, j'ai lu que c'était géré par l'OS afin de dédier des zones mémoires à des programmes et éviter que d'autres viennent écrire dedans, en gros ça donne de la stabilité au systeme.
Mais du coup, je me demandais si ça pouvait avoir un lien avec cette différence que tu avances entre les tailles de bus et taille de procs car techniquement, je ne vois pas vraiment ce que ça apporte sauf si il y a une notion de contrainte de vitesse dans les bus à faire rentrer là dedans mais que je ne détiens pas encore.

Oui je ne doute pas qu'Internet regorge d'informations intéressantes, c'est juste qu'on peut passer beaucoup de temps à lire des choses et à comprendre de travers (la preuve).
C'est donc là pour moi l'intérêt de cette discussion, affiner ce qui n'est pas compris et avoir des biais de recherches pour ce qui est à explorer.
Par contre, ça m'a semblé assez logique de m'approprier la bibliographie utilisée pour les cours de licence que je vais commencer l'année prochaine, ça me permet d'avoir une culture sur là où je vais mettre les pieds et dans quelles conditions et sur quoi seront basés les supports.

Oui certainement, tu as raison qu'avec une phase de pratique les choses s'éclairciront très certainement.
Pour le coup, j'avoue que le transistor m'a plus aidé à conceptualiser le registre sous sa forme physique qu'une ligne d'assembleur mais je n'y manquerai pas.



Merci pour ta réactivité et ta patience du coup

[Kannagi]

Pour le moment l'impression que j'ai , c'est que tu n'y comprend pas grand chose et que tu mélange beaucoup de chose , et donc internet peut aider peut être à te focaliser que sur quelque thème , qu'un gros bouquin ultra généraliste que tu comprendra pas forcément grand chose , mais c'est juste mon avis

Oui j'ai bien lu ton exemple mais je ne comprends pas trop l'intérêt de ce choix technique (économique tu me diras).
Si tu as un processeur de 16bits et un bus de 8bits, j'ai l'impression que ça force le processeur à travailler "lentement" qq part en donnant moins que ce qu'il est capable de prendre.

Parce que tu peux prendre du coup de la RAM 8 bits qui ne coûtais pas grand chose à l'époque , même si c'est plus lent

Idem à l'inverse, ton procs de 64bits à qui on envoie 256bits, j'ai un peu du mal à voir comment il gère ça mais j'y verrai sans doute plus clair quand j'aurai commencé et fini le chapitre sur le processeur.

Plus exactement , c'est en lecture/écriture , et 256 bits c'est donc 4 x64 bits , et il faut savoir qu'on fait plusieurs load/store sur les proc moderne
Inversement , ça te permet de charger 2 vecteur 128 bits ,très utilisé pour les calcul 3D ou autre calcul haute perf
Ou tout simplement lire/écrire sur un vecteur 256 bits , il ne faut pas oublier qu'on fait une gravure, donc tu dois toujours gérer le pire des scénarios et le pire est quand tu dois lire ou écrire 256 bits

Du coup, c'est pour ça que j'en suis venu sur la mémoire virtuelle, car en effet, j'ai lu que c'était géré par l'OS afin de dédier des zones mémoires à des programmes et éviter que d'autres viennent écrire dedans, en gros ça donne de la stabilité au systeme.
Mais du coup, je me demandais si ça pouvait avoir un lien avec cette différence que tu avances entre les tailles de bus et taille de procs car techniquement, je ne vois pas vraiment ce que ça apporte sauf si il y a une notion de contrainte de vitesse dans les bus à faire rentrer là dedans mais que je ne détiens pas encore.

Là encore ,tu mets des lien où il y'en a aucun , on pourrais avoir des différences de tailles et ne pas avoir de mémoire virtuel.
Comme je le redis, c'est juste pour l'OS , pas pour la stabilité (laquelle d'ailleurs ? ), juste de la sécurité que les programmes n'écrive pas ailleurs que dans les adresses qu'on leur demande.

[foetus]

Je ne suis pas revenu sur la notion de mot
Au début, 1 mot c'est 16 bits (word en anglais). Et de là, à découler dword (double word, 32 bits) et qword (quad word, 64 bits)
Si tu travailles avec la WinApi de Microsoft en C, c'est présent.

Mais au fil du temps, le mot est devenu "1 paquet de données" (ou "1 paquet de données multiple de 16")

wikipedia mot en fraçais

En revanche, au niveau architecture matérielle, le « mot » est basiquement la taille du bus mémoire, soit la taille de la donnée unitaire capable de transiter entre les zones de stockage mémoire et les registres du processeur central (voir plus bas). Cette taille n'est pas normalisée, mais est généralement un multiple entier ou fractionnaire du mot « logiciel », c'est-à-dire un multiple de 16.

Pour la mémoire cache, les processeurs x86/ x64 ont 3 niveaux L1, L2 et L3.
Mais depuis les processeurs multicores, les caches L1 et L2 ont des utilisations très très spécifiques (parce qu'ils sont partagés) et sont divisés entre cores (même le L3 apparemment)

Pour le coup, j'avoue que le transistor m'a plus aidé à conceptualiser le registre sous sa forme physique qu'une ligne d'assembleur mais je n'y manquerai pas.:

Tiens si cela peut t'éclairer 1 peu (8-bit CPU control logic: Part 1)

[AxAx_]

Pour le moment l'impression que j'ai , c'est que tu n'y comprend pas grand chose et que tu mélange beaucoup de chose , et donc internet peut aider peut être à te focaliser que sur quelque thème , qu'un gros bouquin ultra généraliste que tu comprendra pas forcément grand chose , mais c'est juste mon avis

Personnellement, j'ai du mal à comprendre en quoi c'est juste une impression puisque j'en fais l'aveu depuis mon premier poste.
J'avoue que si je comprenais tout et que je savais tout, je ne serais probablement pas là à poser des questions mais bien là à un tout autre niveau d'implication sur ce forum.

Là encore ,tu mets des lien où il y'en a aucun , on pourrais avoir des différences de tailles et ne pas avoir de mémoire virtuel.
Comme je le redis, c'est juste pour l'OS , pas pour la stabilité (laquelle d'ailleurs ? ), juste de la sécurité que les programmes n'écrive pas ailleurs que dans les adresses qu'on leur demande.

Je suis un peu désolé d'insister mais la mémoire virtuelle gérée par l'unité de gestion de mémoire ou MMU est utilisée par l'OS,
l'OS attribue une zone mémoire protégée dans laquelle un autre programme ne pourra pas écrire.

Moi ça me semble logique ... si un logiciel vient squatter l'adresse déjà prise et servant au fonctionnement d'un autre... ça nuit clairement à la stabilité du système...
Donc oui, comme tu dis, c'est une sécurité ... Mais une sécurité pourquoi ? Pour pas qu'un programme vienne créer une défaillance dans un autre.
J'essaie pas forcément d'avoir raison mais bon ... là je t'avoue que je croise plusieurs (ok ... 2) sources allant dans ce sens ...

-> " Ce principe de protection mémoire est la caractéristique la plus cruciale pour bénéficier d'un système d'exploitation stable. Les anciens systèmes d'exploitation qui n'en bénéficiaient pas plantaient souvent, selon que les programmes exécutés comportaient des erreurs de conception ou non. Il fallait alors redémarrer toute la machine. "

Je ne suis pas revenu sur la notion de mot
Au début, 1 mot c'est 16 bits (word en anglais). Et de là, à découler dword (double word, 32 bits) et qword (quad word, 64 bits)
Si tu travailles avec la WinApi de Microsoft en C, c'est présent.

Mais au fil du temps, le mot est devenu "1 paquet de données" (ou "1 paquet de données multiple de 16")

wikipedia mot en fraçais



Pour la mémoire cache, les processeurs x86/ x64 ont 3 niveaux L1, L2 et L3.
Mais depuis les processeurs multicores, les caches L1 et L2 ont des utilisations très très spécifiques (parce qu'ils sont partagés) et sont divisés entre cores (même le L3 apparemment)



Tiens si cela peut t'éclairer 1 peu (8-bit CPU control logic: Part 1)

Yes merci beaucoup, c'est top.

[foetus]

Je suis un peu désolé d'insister mais la mémoire virtuelle gérée par l'unité de gestion de mémoire ou MMU est utilisée par l'OS,

Je ne veux pas rentrer dans les détails mais la mémoire virtuelle permet également d'utiliser + de mémoire (avec de la mémoire dans 1 swap) et faire du multitâche.
Et cela va + loin : mode protégé vs mode réel, pagination de la mémoire, ...
Tout cela peut-être spécifique aux processeurs x86/ x64 (mais à vérifier)

[Kannagi]

Je suis un peu désolé d'insister mais la mémoire virtuelle gérée par l'unité de gestion de mémoire ou MMU est utilisée par l'OS,
l'OS attribue une zone mémoire protégée dans laquelle un autre programme ne pourra pas écrire.

Moi ça me semble logique ... si un logiciel vient squatter l'adresse déjà prise et servant au fonctionnement d'un autre... ça nuit clairement à la stabilité du système...
Donc oui, comme tu dis, c'est une sécurité ... Mais une sécurité pourquoi ? Pour pas qu'un programme vienne créer une défaillance dans un autre.
J'essaie pas forcément d'avoir raison mais bon ... là je t'avoue que je croise plusieurs (ok ... 2) sources allant dans ce sens ...

-> " Ce principe de protection mémoire est la caractéristique la plus cruciale pour bénéficier d'un système d'exploitation stable. Les anciens systèmes d'exploitation qui n'en bénéficiaient pas plantaient souvent, selon que les programmes exécutés comportaient des erreurs de conception ou non. Il fallait alors redémarrer toute la machine. "

Oui c'est ce que je dis , ai-je dis que le MMU n'étais pas utilisé par l'OS ?
Vu que c'est bien lui qui indique le TLB , par contre les programmes ne peuvent modifié le MMU , mais passe par lui
ça permet que les programmes n'écrivent pas partout , pour la sécurité ,ou stabilité appelle à ça comme tu veux
Mais pour moi un programme qui n'écrit pas ailleurs, c'est avant tout une question de sécurité que de stabilité.

-> " Ce principe de protection mémoire est la caractéristique la plus cruciale pour bénéficier d'un système d'exploitation stable. Les anciens systèmes d'exploitation qui n'en bénéficiaient pas plantaient souvent, selon que les programmes exécutés comportaient des erreurs de conception ou non. Il fallait alors redémarrer toute la machine. "

Oui , mais il me semble que le M68000 avait une sécurité contre ça pour éviter que les programmes faisait n'importe quoi , on aurotrisant les programmes à écrire qu'a la mémoire haute , laissant ainsi l'OS tranquille.
D'ailleurs l'Amiga était réputé pour être assez stable

[AxAx_]

Oui c'est ce que je dis , ai-je dis que le MMU n'étais pas utilisé par l'OS ?
Vu que c'est bien lui qui indique le TLB , par contre les programmes ne peuvent modifié le MMU , mais passe par lui
ça permet que les programmes n'écrivent pas partout , pour la sécurité ,ou stabilité appelle à ça comme tu veux
Mais pour moi un programme qui n'écrit pas ailleurs, c'est avant tout une question de sécurité que de stabilité.



Oui , mais il me semble que le M68000 avait une sécurité contre ça pour éviter que les programmes faisait n'importe quoi , on aurotrisant les programmes à écrire qu'a la mémoire haute , laissant ainsi l'OS tranquille.
D'ailleurs l'Amiga était réputé pour être assez stable

Oula, ça tu as surement raison mais j'avoue que je n'ai pas connu l'Amiga
En tout cas merci pour tout.
Je reviens dans un chapitre sauf si ça va ... Mais il m'a l'air vraiment vilain celui là.

[chrtophe]

J'ai donc compris qu'il y avait une hiérarchisation des systèmes de stockages et que le registre était au top de la pyramide en terme de vitesse ce qui visiblement est inversement proportionnel à sa capacité sur un système comparé aux autres unités de stockages pour des raisons de coût.

En gros, plus le système de stockage est rapide, plus il coûte cher et donc moins on en met.

c'est l’essentiel qu'il te faut garder en mémoire. Tout le reste n'est à ton niveau que complexité et détail qui sont inutiles en premier niveau. D’où la confusion. Globalement, tu n'exploiteras la notion de registre que si fais de l'assembleur. La complexité de tout ça vient surtout comme l'expliquais mes collègues de stratagèmes pour réduire les coups, la RAM étant à l'époque extrêmement cher et/ou améliorations (exemple CPU 32 bits, bus 16 bits : cout moindre mais perfs aussi ou sur les très vieux CPU un seul bus pour les adresses et les données). Beaucoup de notions sont maintenant obsolètes comme les histoires de registres généraux/spécialisés (sauf cas très précis comme évoqué), mais elles sont toujours implémentés pour des questions de rétrocompatibilité. Exemple un CPU Intel dernière génération peut toujours fonctionner en mode réel comme un 8086 des années 80 (je parle niveau CPU, pas OS).

Pour la mémoire virtuelle, pareil, c'est avant tout historique. Les CPU étaient auparavant limitées en capacité mémoire de par la taille de leur bus notamment, et les machines intégraient beaucoup moins de mémoire que les capacités de gestion du CPU, vu leur prix. Sont alors apparus des cartes d'extensions mémoire, des "ruses" étant utilisés permettant de présenter la mémoire supplémentaire en fenêtres dans l’espace d’adressage du CPU : la mémoire EMS peut-être évoqué dans ton bouquin, ancêtre de la pagination. L'adressage sous forme de segment:offset du x86 facilitant d'ailleurs cela. Sont apparus ensuite des composants dédiés à cela : la MMU permettant de virtualiser les adresses mémoires et donc soit de présenter plus de mémoire que dispo, et/ou isoler la RAM par processus (avec les anciens systèmes type MS-DOS, n'importe quel logiciel écrivait ou il voulait en mémoire, l'OS n'était ni multitâche, ni multi-utilisateur, et aucune protection). la MMU est soit intégrée dans le CPU (cas des x86-AMD64) soit un composant câblé d'un coté sur le CPU et de l'autre sur le BUS mémoire.
De nos jours, c'est l'OS qui gère cet aspect. si tu fais de la programmation, comprendre ce fonctionnement te permettra de comprendre les erreurs de type "violation de privilège" "segfault".

[Mat.M]

J'ai donc compris qu'il y avait une hiérarchisation des systèmes de stockages

bonjour se renseigner sur le modèle O.S.I. qui est une forme de standard dans le numérique.

Mais ne perdez-pas trop votre temps à comprendre comment ça fonctionne un microprocesseur..à moins de travailler dans la R&D chez Huaweii ou un fabricant de chipsets pour des cartes graphiques.
c'est bien de connaître le fonctionnement d'un microprocesseur mais en entreprise et notamment pour réaliser des logiciels de gestion vos compétences sur un E.R.P. (niveau applicatif donc 7 du modèle OSI) seront bien plus appréciées car comme je l'ai déjà écris le monde de l'entreprise fonctionne avant tout par solutions informatiques tout intégré.
Le client lui il veut que vous sortiez une liste comptable de clients en incidence de paiement ;
que vous lui expliquiez les registres EAX,EBX, l'accumulateur le registre de pile, le mode protégé i386...il s'en fiche