A voir également:
- Qu'est-ce que l'alignement
- Problème alignement imprimante hp - Forum Imprimante
- Supprimer alignement cartouche hp ✓ - Forum Imprimante
- Probleme d' alignement des cartouches - Forum Imprimante
- Problème alignement flèche word - Forum Word
- L imprimante imprime une page de test au demarrage - Forum Imprimante
6 réponses
Cela facilite les accès mémoires. En effet, lorsque l'on transfere une instruction ou une donnée (à ce stade, c'est fondamentalement la même chose) elle transite par un bus, une trame de fils, 32 pour les 32bits des processeurs actuels, soit donc 4 octets, un alignement sur 4. (D'ailleurs, Seb, ça fait pas un peu beaucoup, 32 ? 256bits, connais ni ce bus, ni ce proce là, mais je suis pas top calé matos dernier cri... ;°)
Bref, suivons le raisonnement avec deux octets (align 2, 16bits). Il faut voir que l'octet de poids fort est branché sur la partie poids fort (adresses impaires des octets en mémoire et le poids faible sur la partie poids faible (adresses paire).
Si le proce demande de transférer une donnée (ou une instruction) 16bits depuis une adresse paire, on dit que "c'est aligné" puisque la mémoire, en un seul coup, peux cracher sur le bus, et l'octet de poids faible, et celui de poids fort. Si au contraire, les 16bits sont calés à une adresse impaire, la mémoire va être obligée de transferer, dans un premier temps l'octet de poids faible, situé à une adresse impaire, sur la partie "poids fort" du bus, puis ensuite, car entre temps elle aura incrémenté son compteur d'adresse, la partie de poids fort, aligné sur une adresse paire, sur la partie "poids faible" du bus.
Hors le bus est ce qui ralenti le plus un système (par comparaison, mon 2GHz pédale sur un bus à 333 ou 400MHz, je sais plus). Toujours est-il que vu que la période du bus est beaucoup plus faible (raisons de consomation, échauffement, etc... raisons physiques, quoi...) il est NECESSAIRE d'optimiser les transferts.
Les compilo que je connais aligne toujours les données en mémoire (par exemple un caractère seul + un entier risques fort d'occuper 8 octets en mémoire au lieu de 5).
Comme l'a précisé Seb, l'option sert à le faire pour les instructions.
Bref, suivons le raisonnement avec deux octets (align 2, 16bits). Il faut voir que l'octet de poids fort est branché sur la partie poids fort (adresses impaires des octets en mémoire et le poids faible sur la partie poids faible (adresses paire).
Si le proce demande de transférer une donnée (ou une instruction) 16bits depuis une adresse paire, on dit que "c'est aligné" puisque la mémoire, en un seul coup, peux cracher sur le bus, et l'octet de poids faible, et celui de poids fort. Si au contraire, les 16bits sont calés à une adresse impaire, la mémoire va être obligée de transferer, dans un premier temps l'octet de poids faible, situé à une adresse impaire, sur la partie "poids fort" du bus, puis ensuite, car entre temps elle aura incrémenté son compteur d'adresse, la partie de poids fort, aligné sur une adresse paire, sur la partie "poids faible" du bus.
Hors le bus est ce qui ralenti le plus un système (par comparaison, mon 2GHz pédale sur un bus à 333 ou 400MHz, je sais plus). Toujours est-il que vu que la période du bus est beaucoup plus faible (raisons de consomation, échauffement, etc... raisons physiques, quoi...) il est NECESSAIRE d'optimiser les transferts.
Les compilo que je connais aligne toujours les données en mémoire (par exemple un caractère seul + un entier risques fort d'occuper 8 octets en mémoire au lieu de 5).
Comme l'a précisé Seb, l'option sert à le faire pour les instructions.
maily
Messages postés
7556
Date d'inscription
lundi 26 juin 2000
Statut
Contributeur
Dernière intervention
23 juin 2023
453
31 mars 2005 à 14:23
31 mars 2005 à 14:23
bonjour!
quel langage?
quel langage?
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
31 mars 2005 à 15:26
31 mars 2005 à 15:26
ça existe dans pratiquement tous les compilateurs.
ça sert à aligner les instructions langage machine sur des adresses mémoire multiples de 4, 8, 16 ou 32.
Cela facilite le travaille du microprocesseur et de la gestion mémoire et lui permet d'exécuter plus vite les programmes.
Contrepartie: les programmes un peu plus volumineux.
En générale, il est recommand d'aligner quand on fait la compilation finale (avant de distribuer le programme).
ça sert à aligner les instructions langage machine sur des adresses mémoire multiples de 4, 8, 16 ou 32.
Cela facilite le travaille du microprocesseur et de la gestion mémoire et lui permet d'exécuter plus vite les programmes.
Contrepartie: les programmes un peu plus volumineux.
En générale, il est recommand d'aligner quand on fait la compilation finale (avant de distribuer le programme).
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
1 avril 2005 à 09:27
1 avril 2005 à 09:27
oui 32, je pousse un peu quand même.
Merci les gars pour vos lumières
Est-ce que cette affaire (le non alignement dans ma compil) peut expliquer ceci:
J'ai compilé un code sous tru64, marche TB sur un cas simple
Le même cas compilé (avec les mêmes options à savoir -O tout simplement) sous Linux RedHat 9 marche mais avec apparemment des blocages liés soit à de la dble précision ou des défauts de précisions d'ordre général (plantages inexpliqués)
Qu'en pensez vous ?
Est-ce que cette affaire (le non alignement dans ma compil) peut expliquer ceci:
J'ai compilé un code sous tru64, marche TB sur un cas simple
Le même cas compilé (avec les mêmes options à savoir -O tout simplement) sous Linux RedHat 9 marche mais avec apparemment des blocages liés soit à de la dble précision ou des défauts de précisions d'ordre général (plantages inexpliqués)
Qu'en pensez vous ?