Dans un livre, j'ai lu ce qui suit :
Les processeurs 32 bits ont 2^32 adresses possibles, tandis que les processeurs 64 bits actuels ont un espace d'adressage de 48 bits.
Je m'attendais à ce que, si c'est un processeur 64 bits, l'espace d'adressage soit également 2^64.
Je me demandais donc quelle était la raison de cette limitation ?
Parce que c'est tout ce qu'il faut. 48 bits vous donnent un espace d'adressage de 256 téraoctets. C'est beaucoup. Vous ne verrez pas de sitôt un système ayant besoin de plus que cela.
Les fabricants de processeurs ont donc pris un raccourci. Ils utilisent un jeu d'instructions qui permet un espace d'adressage complet de 64 bits, mais les CPU actuels n'utilisent que les 48 bits inférieurs. L'alternative consistait à gaspiller des transistors pour gérer un espace d'adressage plus important qui ne serait pas nécessaire avant de nombreuses années.
Ainsi, lorsque nous nous approcherons de la limite des 48 bits, il suffira de mettre sur le marché des processeurs capables de gérer l'intégralité de l'espace d'adressage, mais cela ne nécessitera aucune modification du jeu d'instructions et ne rompra pas la compatibilité.
@bdares : Mauvaise analogie. Le jeu d'instructions de l'arc 8088/8086 a une limite de 640k intégrée. Ce n'est qu'en créant une nouvelle ISA (386) qu'il a été possible de briser cette barrière. x86_64, d'un autre côté, supporte tous les 64 bits de l'ISA. C'est juste le matériel de la génération actuelle qui ne peut pas les utiliser tous...
Toute réponse faisant référence à la taille du bus et à la mémoire physique est légèrement erronée, puisque la question de l'OP portait sur espace d'adressage virtuel pas espace d'adresse physique . Par exemple, la limite supposée analogue sur certains 386 était une limite sur la mémoire physique qu'ils pouvaient utiliser, et non sur l'espace d'adressage virtuel, qui était toujours de 32 bits. En principe, vous pouvez utiliser un espace d'adressage virtuel de 64 bits, même avec seulement quelques Mo de mémoire physique ; bien sûr, vous pouvez le faire par swapping, ou pour des tâches spécialisées où vous voulez mapper la même page à plusieurs adresses (par exemple, certaines opérations de données éparses).
Je pense que la vraie réponse est qu'AMD était juste bon marché et espérait que personne ne s'en soucierait pour le moment, mais je n'ai pas de références à citer.
"Être bon marché", je suppose que vous voulez dire ne pas ajouter de broches qui ne seront jamais utilisées, ne pas prendre de place sur la puce pour des transistors qui ne seront pas utilisés et utiliser l'espace libéré pour rendre les instructions existantes plus rapides ? Si c'est ça être bon marché, j'en suis !
Le 80386 permet 2 * 4096 sélecteurs contenant chacun jusqu'à 4 Go de mémoire (32 To au total). Le 80286 permet 2 * 4096 sélecteurs contenant chacun jusqu'à 64KB (1GB).
Les hacks segmentés non linéaires ne comptent pas comme espace d'adressage dans mon livre. Il n'y a aucun moyen pour un logiciel portable d'en faire un usage quelconque.
Il y a une raison plus grave que la simple économie de transistors dans le chemin d'adresse du CPU : si vous augmentez la taille de l'espace d'adressage, vous devez augmenter la taille des pages, augmenter la taille des tables de pages, ou avoir une structure de table de pages plus profonde (c'est-à-dire plus de niveaux de tables de traduction). Tous ces éléments augmentent le coût d'un échec de la TLB, ce qui nuit aux performances.
Intel propose un schéma de pagination à 5 niveaux pour passer de 48 bits actuellement à 57 bits. (Même 9 bits par niveau / 4k pages que les tables de pages actuelles de x86-64). L'utilisation de 10 ou 11 bits par niveau aurait nécessité une modification du matériel de défilement des pages, ce qui n'est peut-être pas la conception optimale pour une mémoire énorme, mais c'est une extension raisonnable pour un processeur bimode qui doit également supporter des performances maximales pour les tables à 4 niveaux dans le format actuel.
La largeur de registre/opération native interne n'est pas besoin de pour se refléter dans la largeur du bus d'adresse externe.
Disons que vous avez un processeur 64 bits qui n'a besoin que d'accéder à 1 mégaoctet de RAM. Un bus d'adresse de 20 bits est tout ce qui est nécessaire. Pourquoi s'embêter avec le coût et la complexité matérielle de toutes les broches supplémentaires que vous n'utiliserez pas ?
Le Motorola 68000 était ainsi : 32 bits en interne, mais avec un bus d'adresse de 23 bits (et un bus de données de 16 bits). L'unité centrale pouvait accéder à 16 mégaoctets de RAM, et pour charger le type de données natif (32 bits), il fallait deux accès à la mémoire (chacun portant 16 bits de données).
Mais le 68000 est considéré comme un processeur "16/32 bits", pas un processeur "complet" 32 bits, donc on pourrait dire qu'il a encore un pied dans le passé 16 bits ; j'ai choisi le 68020 comme exemple, puisque sa version 68EC020 à bas prix a 24 bits seulement pour les adresses, bien que le 68020 soit un processeur "complet" 32 bits... +1 d'avoir considéré cette merveilleuse famille de processeurs !
@ShinTakezou : honnêtement, le 80386SX était-il un CPU 16 bits (parce qu'il avait un espace d'adressage comme le 80286) ou était-il 32 bits (parce qu'il avait l'architecture interne d'un 80386DX) ? On pourrait dire comme vous, mais un autre (celui-ci) dit "l'interne est ce qui compte" - et vous pouvez me citer à ce sujet.
@Olof Je pense que, dans le contexte de la "mémoire" (qui est le monde extérieur), c'est l'extérieur qui compte, donc 68000 est une unité centrale de traitement de 16 bits (nécessitant 2 "étapes" pour lire des données de 32 bits) :D
De nombreuses personnes ont cette idée fausse. Mais je vous promets que si vous lisez ceci attentivement, après avoir lu ceci, toutes vos idées fausses disparaîtront.
Dire qu'un processeur est de 32 ou 64 bits ne signifie pas qu'il doit avoir un bus d'adresse de 32 ou 64 bits respectivement... Je répète que ce n'est pas le cas !
Un processeur 32 bits signifie qu'il possède une ALU (unité arithmétique et logique) de 32 bits... ce qui signifie qu'il peut opérer sur un opérande binaire de 32 bits (ou simplement un nombre binaire de 32 chiffres) et de la même manière, un processeur 64 bits peut opérer sur un opérande binaire de 64 bits. Ainsi, le fait qu'un processeur soit de 32 ou 64 bits ne signifie pas que la quantité maximale de mémoire peut être installée. Ils montrent simplement la taille de l'opérande... (par analogie, vous pouvez penser à une calculatrice à 10 chiffres qui peut calculer des résultats jusqu'à 10 chiffres... elle ne peut pas nous donner 11 chiffres ou tout autre résultat plus grand... bien que ce soit en décimal, mais je raconte cette analogie pour simplifier)... mais ce que vous dites est l'espace d'adressage qui est la taille maximale directement interfaçable de la mémoire (RAM). La taille maximale possible de la RAM est déterminée par la taille du bus d'adresse et ce n'est pas la taille du bus de données ou même de l'ALU sur laquelle est définie la taille du processeur (32/64 bits). Oui, si un processeur a un "bus d'adresse" de 32 bits, alors il est capable d'adresser 2^32 octets = 4GB de RAM (ou pour 64 bits, ce sera 2^64)... mais dire qu'un processeur a 32 ou 64 bits n'a rien à voir avec cet espace d'adressage (espace d'adressage = jusqu'où il peut accéder à la mémoire ou la taille maximale de la RAM) et cela dépend uniquement de la taille de son UAL. Bien sûr, le bus de données et le bus d'adresse peuvent être de la même taille et alors il peut sembler qu'un processeur 32 bits signifie qu'il accèdera à 2^32 octets ou à 4 Go de mémoire... mais ce n'est qu'une coïncidence et ce ne sera pas la même chose pour tous.... par exemple l'intel 8086 est un processeur 16 bits (car il a une UAL 16 bits) donc comme vous le dites il devrait avoir accès à 2^16 octets = 64 Ko de mémoire mais ce n'est pas vrai. Il peut accéder jusqu'à 1 MB de mémoire pour avoir un bus d'adresse de 20 bits....Vous pouvez chercher sur Google si vous avez des doutes :)
Je pense que mon point de vue est clair. Maintenant, pour en venir à votre question... comme un processeur de 64 bits ne signifie pas qu'il doit avoir un bus d'adresse de 64 bits, il n'y a rien de mal à avoir un bus d'adresse de 48 bits dans un processeur de 64 bits... ils ont gardé l'espace d'adresse plus petit pour rendre la conception et la fabrication bon marché.... comme personne ne va utiliser une mémoire aussi grande (2^64 octets)... où 2^48 octets sont plus que suffisants de nos jours.
Je pense que vous avez été très clair, mais il y a une chose que je ne comprends pas dans ce que vous avez dit sur le CPU 16 bits 8086 : comment un CPU 16 bits peut-il traiter une adresse de 20 bits ? Est-ce qu'il la traite par une opération en 2 étapes ? Même si le bus d'adresse a une largeur de 20 bits, une fois qu'il arrive au CPU, la largeur du registre ne peut évidemment prendre que 16 bits ... Comment font-ils cela ?
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
19 votes
Le livre devait parler spécifiquement de l'implémentation actuelle de l'architecture AMD64 (x86-64). Seuls les 48 bits de poids faible sont utilisés. Il ne s'agit pas d'une limitation matérielle, cependant - tous les 64 bits sont disponibles.
13 votes
C'est toujours une bonne idée d'identifier le livre.
1 votes
Je suppose que les lignes d'adresses physiques ne sont pas libres (il faut au moins 16 broches supplémentaires pour le processeur). Et je ne connais pas encore de matériel capable de remplir un espace de 48 bits avec des puces de RAM physique sur le même processeur. Lorsque cela deviendra possible, je suis sûr qu'AMD ajoutera les 16 broches manquantes :)
0 votes
@Cody : Je sais ce que vous voulez dire, mais n'est-ce pas exactement une limitation matérielle, si elle est spécifique à l'implémentation actuelle de l'AMD64 ;)
8 votes
Même,
The 32-bit processors have 2^32 possible addressesn'est pas nécessairement vrai, il peut exister des processeurs 32 bits avec seulement 24 "broches" pour l'adressage de la mémoire. Par exemple, le 68EC020 (version 68020 moins chère) est un processeur 32 bits mais avec 24 bits pour l'adressage de la mémoire.28 votes
Il y a un problème très réel avec l'adressage physique 64 bits, la taille des pages de la mémoire virtuelle est trop petite. Il en résulte d'énormes répertoires de pages et des vidages de cache TLB extrêmement coûteux à chaque changement de contexte. Passer de 4KB à 4MB est une option, mais elle est très incompatible avec les systèmes d'exploitation actuels.
1 votes
En outre,
The 32-bit processors have 2^32 possible addressesest plutôt vague ; par exemple, un certain nombre de CPU x86 32 bits (généralement des serveurs/stations de travail) prennent en charge le PAE, qui permet un espace d'adressage physique de 36 bits. Un certain nombre de CPU x86_64 modernes prennent en charge un espace d'adressage physique de 48 bits et un espace d'adressage virtuel de 52 bits.1 votes
@HansPassant Pouvez-vous développer ce point ? Je ne suis pas tout à fait sûr de ce que vous voulez dire. Comment la taille de la page individuelle d'un système d'exploitation est-elle liée à l'espace d'adressage ? En quoi le fait de modifier la taille des pages permet-il d'augmenter l'espace d'adressage physique ?
1 votes
@AaronFranke : pour une taille de page et un nombre d'entrées TLB fixes, vous ne pouvez couvrir qu'une quantité fixe de la taille de l'ensemble de travail virtuel. Avec plus de RAM, c'est une fraction de plus en plus petite de la mémoire disponible, et comme la bande passante de la mémoire s'améliore, vous mâchez cet ensemble plus rapidement et obtenez plus d'échecs TLB. Mais je pense que Hans parlait principalement de la quantité d'espace nécessaire uniquement pour les tables de pages afin d'indiquer au CPU où se trouve la page physique pour chaque page virtuelle. Avec des tables de pages imbriquées plus profondément, le page walker est plus coûteux, et les TLB plus grandes coûtent plus cher si vous les videz toutes.