Ça fait quasiment 3 jours que je fais des recherches sur l'alignement des adresses mémoire sans trouver exactement l'information que je cherche,
donc ça me ferait énormément plaisir si quelqu'un pouvait répondre à ma question.
Pourquoi est-ce-que la plupart des processeurs exigent que l'adresse d'une donnée soit un multiple de la taille (en byte) de la donnée ?
Je sais que ça peut améliorer les performances en évitant au processeur d'effectuer plusieurs opérations de plus pour récupérer une donné,
mais pourquoi le processeur ne récupère - t - il pas tout simplement la donnée stockée à l'adresse qu'on lui donne puisque tous les bytes ont une adresse en mémoire?
Est-ce une contrainte électronique au niveau de la conception du processeur ? Est-ce parce qu'il passe par la mémoire cache et que celle-ci n'adresse pas les donnés par byte?
Mais je le remet ici pour ceux qui se poserai la même question donc je répond à " l'adresse d'une donnée soit un multiple de la taille (en byte) de la donnée"
-Tu as effectivement le cache , qui a un alignement de 32 ou 64 octets ,donc si tu voulais lire 4 octet à l'adresse + 30 (sur une ligne de cache de 32) , ça poserait un sacré soucis - tu as aussi les opcodes qui défini l'adresse , les processeurs RISC ont un opcode fixe (ARM,PowerPC,RISC-V etc etc) , il est plus "logique" que les types plus grand lise plus de mémoire. Si on a une adresse relative sur 16 bits,(pour le SP) sur un byte on peut lire l'adresse de 0 à 64ko , sur 2 bytes , on peut lire pareil 65536 élément , mais par pair de 2 bytes (donc de 0 à 128ko) etc etc. -Tu as aussi les DDR actuelle qui sont pensé pour les proc actuelle (donc de fournir 8 octets /cycles ,et de pouvoir accélérer les transferts pour les lignes de cache donc 32/64 octets).
Alignement des adresses mémoire
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.