Avec 48bits, vous pouvez adresser 256TiB de RAM, beaucoup d'espace pour être utile

Ce n'est pas une question d'espace d'adressage (*).

En fait, la plupart des processeurs de bureau 64 bits ont un bus d'adresses 48 bits. Il n’y a pas grand intérêt à aller plus loin que ça, vous avez raison.

Il semble qu'en général, les nombres 32 bits sont déjà très grands pour la plupart des calculs entiers et décimaux

Beaucoup, mais pas tous, et probablement pas la plupart. De nombreux calculs (même sur des processeurs 32 bits) finissent par utiliser des calculs 64 bits

L'exemple le plus simple de ceci est le bogue Y2k38 qui viendra mordre tout système utilisant un horodatage Unix 32 bits dans les 20 prochaines années.

De nombreux nombres à virgule flottante sont à double précision (64 bits) car un flottant à simple précision donne une plage très limitée.

Les processeurs 64 bits peuvent également effectuer des calculs 32 bits, et en fait, avoir des caches 64 bits permet de stocker deux fois plus de valeurs 32 bits dans le cache, ce qui accélère potentiellement les performances en réduisant les opérations de mémoire (cache manque )

Les processeurs 64 bits modernes prenant en charge des instructions avancées de style SIMD peuvent également effectuer plusieurs opérations 32 bits simultanément, de sorte que même les calculs 32 bits peuvent en bénéficier.

Alors pourquoi les concepteurs de processeurs ont-ils choisi de passer à 64 bits si tôt?

Là où le 64 bits entre en jeu, c'est le bus de données. Nous avons tendance à aimer travailler avec une puissance de deux multiples de notre valeur de base - dans les ordinateurs, il s'agit généralement d'un octet de 8 bits. Ainsi, les puissances de deux seraient 8 bits (1 x 8 bits), 16 bits (2 x 8 bits), 32 bits (4 x 8 bits) comme vous le souhaitez. La prochaine étape logique est donc le 64 bits (8 x 8 bits).

Les bus de données 48 bits seraient un nombre d'octets différent de la puissance de deux, ce qui rend les opérations d'adressage plus intéressantes car les données cessent d'être alignées sur une belle puissance de deux frontières multiples. Ce n'est pas impossible à faire, c'est juste assez rare.

(*) Eh bien, c'est un peu.

Bien qu'il existe quelques exceptions, l'industrie informatique s'est largement normalisée sur les octets 8 bits *.

Il est hautement souhaitable que la taille du mot soit une puissance de deux multiple de la taille d'octet. Ne pas le faire entraînerait une traduction d'adresses extrêmement compliquée lorsque le système de bus doit traduire des adresses d'octets en adresses de mots.

Il est également hautement souhaitable de pouvoir manipuler les adresses mémoire en un seul mot de données, en particulier sur un processeur moderne hautement pipeliné.

Il est également hautement souhaitable d’avoir une rétrocompatibilité, ce qui signifie un mode 32 bits. L'ajout d'un support à votre système pour traiter les "demi-mots" est relativement facile, l'ajout d'un support pour le traitement des "deux tiers des mots" serait beaucoup plus compliqué.

Rassemblez ces facteurs et le moyen le plus logique d'augmenter l'espace d'adressage mémoire au-delà de la limite de 32 bits est d'étendre la taille du mot de données à 64 bits. Même si vous ne prévoyez pas immédiatement d'utiliser tous ces bits pour l'adressage de la mémoire (de nombreux systèmes 64 bits ont un espace d'adressage mémoire inférieur à 64 bits).

* Pour les besoins de cet article, "octet" est utilisé pour désigner la plus petite unité de données que le processeur peut adresser, et "mot" est utilisé pour désigner le type de données le plus large que les chemins de données entiers principaux peuvent traiter avec comme une seule unité.

Vous pensez que c'est du gaspillage, mais économiser à un endroit signifie généralement gaspiller dans un autre.

Enregistrer quelques cellules de registre sur la taille des mots vous fait gaspiller des cycles de processeur en manipulant des valeurs mal alignées. Il n'y aurait certainement aucun problème à exécuter de nouveaux programmes entièrement en 48 bits, mais essayer d'exécuter un ancien programme 32 bits sur un processeur 48 bits serait un cauchemar. Tous les transistors que vous auriez pu économiser seraient très probablement remboursés avec intérêts sous la forme d'unités de traitement / traduction 32 bits dédiées. L'alternative serait de casser la rétrocompatibilité, c'est-à-dire "le processeur dont personne n'a besoin".

C'est très similaire à ce qui a tué l'Itanium 64 bits d'Intel: en tant que toute nouvelle architecture, il ne pouvait pas exécuter le code 32 bits hérité aussi vite que l'étirement brut (comparativement) d'AMD de x86 à deux fois la taille du mot. Personne n'est resté là pour voir si le nouveau monde courageux d'Intel finirait par se matérialiser - les coûts de la transition ont effrayé tout le monde. AMD, d'autre part, a apporté "plus de bonnes choses anciennes" et regardez-nous: 16 ans plus tard, nous avons encore des restes de code 32 bits flottant et nos processeurs 64 bits le font tourner plus vite que les processeurs 32 bits.

Ce n'est plus les années 80. L'espace de RAM et de registre n'est plus à la prime maintenant, donc nous ne visons plus "le moins possible". Nous avons plutôt tiré sur «autant que pratique». 64 bits était le plus pratique: comme Tom l'a dit, nous utilisions déjà une précision de 64 bits sur des processeurs 32 bits, mais à mon humble avis, le principal argument de vente était la gestion sans effort de l'héritage.

Sur le marché x86, le traçage du patrimoine jusqu'à IBM XT est une force avec laquelle il faut compter. Et comme une architecture en avait 64, personne ne pouvait vendre en ayant moins. C'est du marketing. Les clients ne comprennent pas ce que c'est, ils savent juste que plus c'est mieux.

J'ai commencé à travailler avec de gros ordinateurs sur un ordinateur avec une largeur de mot de 60 bits adressée par mot, utilisant des unités de 6 bits comme caractères (10 à un mot) bien qu'il y ait plusieurs caractères de 12 bits (comme des lettres minuscules) . Les adresses et les registres d'adresses étaient de 18 bits. C'était un système principalement pour le calcul des nombres: le traitement de texte était nettement gênant car la mémoire n'était pas adressable par caractère.

Alors, qu'est-ce qui ne va pas avec ce genre de configuration aujourd'hui? Les données d'aujourd'hui, pour le meilleur ou pour le pire, sont échangées presque universellement en quantités octets. Les quantités de taille d'octet sont adressées avec des adresses binaires et sont organisées en secteurs / blocs / unités qui ont une taille de puissance de 2 octets. Bien qu'il existe des instructions spéciales adressant des bits dans des contextes très limités, la norme est que les instructions adressent des octets, y compris des instructions qui ne fonctionnent qu'avec des mots entiers. Même sur les processeurs avec des exigences d'alignement strictes (bien que les membres de l'architecture x86 soient assez laxistes ici), les adresses mémoire sont uniformément des adresses d'octets (je me souviens d'un processeur orienté graphique TI où l'unité adressable de base était en fait un seul bit, mais c'était déjà une bizarrerie à son époque)

Les fichiers ont des tailles d'octets et tout se passe à la puissance de 2, les transferts de bus de données réels étant un multiple de la largeur de mot du processeur. Insérer des mots de 48 bits dans ce monde serait cauchemardesque car au lieu de simplement diviser votre adresse en une partie adressant une largeur de bus plus grande et une partie adressant un octet, vous devrez effectuer une division réelle par 6 pour déterminer l'adresse et décalés dans des largeurs de mot plus grandes (vous ne pouvez pas vraiment vous attendre à avoir des dispositifs de mémoire répondant spécifiquement à vos choix de largeur de mot).

En bref: dans un monde de représentations de données et de jeux de caractères normalisés et d'unités périphériques et d'interfaces stockées, utiliser des largeurs de mot autres que des puissances de 2 serait beaucoup plus prohibitif qu'à l'époque où «souris d'ordinateur» ferait référence à des rongeurs creusant des terriersdans les boîtes de cartes perforées, un danger important pour le stockage de données à long terme.

Les développeurs de logiciels N64 ont constaté que le code ISA 64 bits fonctionnait mieux sur le code réel que la compilation pour MIPS ISA 32 bits, car vous pouviez déplacer plus de données et stocker plus de bits dans un espace de registre rapide avec moins d'instructions.

L'ISA 64 bits était bien plus rétrocompatible avec le code 32 bits existant que certains autres registres et tailles de données non power-of 2, ce qui facilitait la programmation et le portage des bibliothèques.

Et la puce du processeur R4200 MIPS n'était que de quelques pour cent plus grande en taille de puce (IIRC, moins de 10%) pour prendre en charge le 64 bits plutôt que simplement le 32 bits MIPS ISA.Gagnez, gagnez.

Tous les concepteurs de puces ne sont pas passés directement à 64 bits depuis 32 bits.Les serveurs IBM S / 38 et les séries de serveurs AS / 400 ultérieurs (désormais IBM System i) utilisaient des puces CISC 48 bits de la fin des années 1970, avant de finalement passer à 64 bits au milieu des années 90.

Une autre raison est le logiciel. Le portage d'un système d'exploitation, ou de toute application qui gère la mémoire de manière complexe, vers une taille de pointeur différente est un travail difficile. Pour un système d'exploitation, tous les pilotes de périphériques ont également tendance à devoir être révisés.

Les éditeurs de logiciels préfèrent ne pas faire ce travail trop souvent; certains d'entre eux ont commencé à porter de 32 bits à 64 bits dans les années 1990 et considèrent le 32 bits comme obsolète à partir de 2019; d'autres commencent seulement maintenant. Cela dépend des marchés qu'ils desservent.

Si tous les éditeurs qui ont historiquement introduit les architectures 64 bits entre 1992 (DEC Alpha) et 2005 (Intel) avaient choisi le 48 bits à la place, alors cela aurait pu être établi. Cependant, à présent, il aurait été trop proche de ses limites pour le confort à l'avenir, et le 64 bits commencerait à arriver.

Si des architectures 64 bits et 48 bits avaient été proposées dans les années 1990, les éditeurs de logiciels clairvoyants auraient ignoré le 48 bits et se seraient concentrés sur les architectures 64 bits. Les entreprises qui avaient opté pour le 48 bits commenceraient maintenant un deuxième cycle de portage et le premier aurait impliqué les complexités d'une taille de pointeur sans puissance de deux, ce qu'elles regretteraient sérieusement.

Les fournisseurs de matériel ont pu voir les grandes lignes de ce scénario dans les années 1990 et ont décidé d'opter pour l'approche qui durerait plus longtemps.

Deux raisons pour 64 bits au lieu de 32:

1. Les nombres à virgule flottante double précision occupent 64 bits (le calcul est en fait effectué en utilisant 80 bits, mais c'est une autre affaire).Une taille de mot machine de 64 bits permet de déplacer de telles valeurs en une seule opération.
2. Les opérations de copie de bloc sont plus rapides plus le bus de données est large, car vous déplacez plus de données à la fois.Cela a rendu les machines 16 bits supérieures à 8 bits et les machines 32 bits supérieures à 16 bits.

À un moment donné dans le futur, les machines 64 bits peuvent céder la place à 128 bits, mais les avantages ne sont pas encore suffisamment convaincants pour les processeurs à usage général, bien que cela puisse déjà être vu dans les processeurs spéciaux comme les GPU.

/ p>

Quant à 32 à 64 au lieu de 48, il est toujours plus pratique (et souvent plus efficace) dans un ordinateur binaire de travailler en puissances de 2. Il ne s'agit pas de taille d'adresse physique, bien que taille d'adresse / taille d'espace mémoire adressableest un facteur contributif.

En fait, si nous parlons du passage d'AMD à 64 bits avec le x86-64, qui révolutionne littéralement la plate-forme, il s'agissait essentiellement de rendre les processeurs Athlon plus puissants que les puces Intel, leur donnant ainsi un avantage concurrentiel sur le marché, comme Intel donnait des coups de pied dans les fesses. Cela a forcé Intel, le leader de l'industrie, à devenir un adepte. Cependant, cela devait être fait en coordination avec Microsoft - sinon le CPU aurait été mort dans l'eau car il ne ferait pas fonctionner Windows.

Intel possédait l'IA-64, mais je pense qu'ils pensaient qu'une telle puissance et ces performances étaient réservées aux entreprises clientes et non au grand public (et bien trop chères), et cela ne fonctionnait pas avec le x86. Mais sans AMD64, Intel fabriquerait encore des processeurs 32 bits aujourd'hui (peut-être avec des fonctionnalités 64 bits comme stratagème marketing).

Mais si vous avez déjà travaillé avec de grandes images Photoshop, des feuilles de calcul Excel massives et des millions d'enregistrements avec SqlServer, vous apprenez à apprécier la capacité des systèmes 64 bits.

Il s'agissait principalement de marketing. AMD a été le premier à publier une architecture 64 bits qui leur a permis de revendiquer la supériorité sur Intel, tandis qu'Intel s'est efforcé de commercialiser ses propres puces 64 bits, précipitées et défectueuses, qui fonctionnaient moins bien que les AMD pendant quelques années.

Ces deux périodes - d'abord où AMD pouvait se vanter d'être la puce la plus avancée alors qu'Intel n'avait pas de puce 64 bits sur le marché, puis ensuite où ils pouvaient se vanter d'être la puce la plus rapide du marché lors de la première tentative d'Intel à 64 bits, les puces n'étaient pas très rapides - cela a permis à AMD de prendre une solide avance en termes de ventes et de performances en 2003/2004 lorsque la transition 64 bits s'est produite.

À l'époque, presque aucun logiciel n'utilisait la puissance supplémentaire offerte par le 64 bits, et même à ce jour, la plupart des applications fonctionnent toujours en mode hérité 32 bits "au cas où"

Outre la prise en charge de pools de mémoire beaucoup plus grands, comme vous l'avez déjà mentionné, les puces elles-mêmes effectuent certains calculs internes plus rapidement en raison de l'espace d'adressage étendu offert par 64 bits, par exemple, vous pouvez combiner 12 valeurs 8 bits en une instruction dans un 64 bits puce alors qu’une puce 32 bits ne pouvait vraiment combiner que 6. Ces gains de performances sont au mieux marginaux, et ont été principalement utilisés à des fins de marketing plutôt que pour des gains de performances réels.

Quant à savoir pourquoi 64 et non 48, deux raisons. L'un était le marketing, 64 est supérieur à 48, et jusqu'à présent, les "bits" des systèmes grand public avaient doublé à chaque fois, 8, 16, 32, le numéro logique suivant dans la séquence était 64. Les consommateurs croiraient (à tort) qu'un Le processeur 64 bits était deux fois plus performant qu'un processeur 32 bits, les incitant à se mettre à niveau plus facilement qu'ils ne le feraient avec un processeur 48 bits. La deuxième raison est plus pratique, un registre 64 bits faisait deux fois la taille de 32 et donc en théorie, il serait plus facile de porter du code sur 64 bits que sur 48.

Hormis les arguments sur la taille des registres, il est logique de «faire le gros ou de rentrer à la maison» lors de l'implémentation de changements globaux dans l'infrastructure informatique globale, pour éviter d'avoir à faire trop souvent une chose aussi horrible.Pour le moment, nous n'avons pas eu besoin de processeurs 128 bits, mais nous passerions probablement de 48 bits à 64 bits à peu près maintenant, il semble donc que c'était un bon appel.