En novembre 2011, ARM annonçait le jeu d'instructions ARMv8, qui a la particularité de proposer la gestion du 64 bits. Quelques mois après cette annonce, et alors qu'ARM n'a toujours pas annoncé de core compatible avec cette architecture, bonne nouvelle : le noyau Linux a été porté sur ce nouveau jeu d'instructions et GCC, le célèbre compilateur, peut sortir du code ARMv8/64 bits.
Si le matériel n'est pas encore annoncé, on sait que le jeu d’instructions est 64 bits, que la mémoire est gérée physiquement sur 48 bits (256 To de RAM au maximum) et la mémoire virtuelle sur 48 bits (256 To). En comparaison, le x86 en 64 bits travaille sur 52 bits pour la mémoire physique et 48 bits pour la mémoire virtuelle. Bien évidemment, les applications classiques, en ARMv7/32 bits, fonctionnent sur un noyau Linux ARMv8/64 bits, comme dans le cas des versions x86. Attention, le noyau Linux actuel limite visiblement les processus à 39 bits pour la mémoire (512 Go), ce qui n'est pas réellement un souci...
La possibilité de compiler du code ARMv8/64 bits (Aarch64) avec GCC est aussi une nouvelle importante : il va être possible de tester le fonctionnement des programmes et de commencer les tests.
Rappelons que les puces ARM actuelles sont 32 bits, même si certains modèles (Cortex A15 et A7) permettent de gérer la mémoire par page à la manière de certains x86 32 bits et 16 bits (LPAE, Large Physical Address Extensions) : la mémoire est gérée physiquement sur 40 bits, mais les applications n'ont accès qu'à 32 bits (et donc 4 Go) à la fois.
Tout le monde ne fait pas de l'informatique avec un ARM.
Belle tentative. Alors je vais te répondre parce que j'aime mettre en boîte ceux qui tentent de le faire. Donc le passage du 8 au 16 bits, ce sont des registres capables de stocker 2^16 = 65536 valeurs au lieu de 2^8 = 256 valeurs, d'où la possibilité de faire des calculs sur des entiers en une seule passe et pas deux avec gestion de la retenue. C'est également une taille mémoire plus grande (16777216 octets adressables avec le 68000 comme avec le 80286) et sans segmentation ou changement de page. Après il y a eu le passage au full-32 bits, avec des registres à 4294967296 valeurs possibles, les fonctions de calcul ad hoc et la même zone mémoire adressable sans pagination. Voilà pour le 32 bits.
Je continue sur l'intérêt du 64bits dans nos pécé (au sens large, càd windows + MacOS + Linux), c'est plus de registres dans le proc (que ne permet l'antique compatibilité x86 et i386) et plus de mémoire adressable à une époque où la moindre trapanelle de supermarché possède 4 GB.
J'espère qu'avec ces chiffres tu as compris que l'ancien que je suis (Pong -> C64 -> Amiga 500 -> Amiga 2000 -> PC) voit tout l'intérêt de cette évolution. Maintenant pour te répondre, et puisqu'il me semble que j'ai affaire à un kador, tu vas m'expliquer l'intérêt d'avoir PLUS de 4GB de RAM dans un automate de grue, de four à µ-ondes, de pilote automatique d'un avion ou de téléphone mobile avec un écran de 7, voire 10 ou 12 pouces si c'est une tablette. Tu n'oublieras pas non plus dans ta démonstration qui sera je n'en doute pas beaucoup plus instructive que ta misérable ironie, l'intéret de registres capables de stocker des valeurs entières de plus de 2^32 pour gérer des systèmes mécaniques dont la précision est au mieux au millionième. Je te rappelle que le premier avion civil à avoir des commandes de vol électrique était le concorde, son système n'avait même pas de µ processeur (pas encore inventé) et le seul qui s'est crashé c'est des suites de l'incendie de ses réservoirs, pas d'un "bug" de son système de commande de vol ; une foultitude de sondes spaciales sont sorties du système solaire avec un 8080 à bord ; les navettes ont volé avec des 8086...
Tu feras un troisième paragraphe sur la mode du 64bits depuis la sortie de l'AMD64 en 2003, et les freins que les grands éditeurs y ont mis (XP64 non traduits, logiciels principaux comme MS Office avec 7 ans de retard sur la technologie, le premier OSX en hybride 32/64...), tu pourras y ajouter que dans le monde libre, cette techno a été prise en compte dès le début avec des versions 64bits des OS libres ET (t'as vu je l'ai souligné et mis en gras) des logiciels associés.
Dans ta conclusion, tu expliqueras que vu l'intérêt du 64bits sur l'ARM, c'est plus qu'un phénomène de mode et que c'est un réel PLUS technologique.
Tu n'as pas compris qu'ARM n'a pas vocation a rester dans les domaines où on le cantonne, et s'ils s'orientent vers le 64 bits ce n'est pas, je pense, par pur plaisir mais bien parce qu'il y a de la demande.
Que cette demande ne corresponde pas à tes domaines de compétence, soit (ce ne sont pas les miens non plus), est-ce une raison pour t'exciter ainsi ? Personne ne t'obliges à te servir des évolutions proposées
Pis parfois on a juste besoin d'efficacité dans les calculs, et plutôt que de mettre un processeur de malade en 32 bits, on en met un moins rapide qui gère du plus gros tout en consommant moins. Ca ne sert que pour quelques rares pointes, mais dans lesquelles le processeur se doit d'assurer grave.
32 bits de plus ont largement leur place dans quasiment toutes les applications. Evidemment peut-être pas dans un four à micro-ondes où une manette de console, mais les applications sont très, très nombreuses, et travaillant moi-même dans le domaine des systèmes embarqués, ça me fait plaisir du 64 bits quand j'y ai le droit.
Voilà. C'est plus constructif comme commentaire. Autrement, concernant la crypto, certains procs comme chez VIA ou les derniers Intel, ont des fonctions AES-NI câblées qui leur permettent d'aller BEAUCOUP plus vite avec cette techno de chiffrement, sans rapport par ailleurs avec l'architecture du processeur...
Enfin bon, si maintenant faut taper une rédac' pour avoir un post qui vaut le coup...