Effectivement tu économises un peu de mémoire (encore que vu la granularité des allocations sur la pile - une page - je suis pas sûr que ca soit visible en pratique pour les variables locales), par contre tu payes très cher en performance en x86[-64] et sur d'autres architectures.
Ça dépend. Ton compilateur peut très bien décider de mettre son char sur 4 octets, parce qu'il pensera que ce sera plus rapide (et de ce que tu lui demandes). Du coup il ne perdra pas de temps. Et il ne gagnera pas de place en mémoire non plus. Par contre, sur d'autres architectures (je ne connais pas bien x86, à ce niveau) il y a des instructions de load non alignées, qui prennent le même temps qu'un load aligné, si je ne me trompe pas. Du coup tu peux gagner de la place sans perdre en performance. Mais c'est plutôt à réserver aux applications où tu en as vraiment besoin, ou éventuellement aux tableaux. Tu ne gagnes globalement rien si tu passes 42 int en char dans tout ton programme. (dans un précédent projet, on avait une table de calibration composée de 2*4*27*27 char si je me rappelle bien. Et 4Mo de RAM, 2Mo de ROM. La différence entre char et int (de 4 octets) c'est 17 ko, presque 1% de la ROM, 0.5% de la RAM.
Pour un exemple de load non aligné, il y a par exemple
ldub address, reg
sur sparc.
Faut faire quand même faire attention, ça peut avoir des effets ailleurs (enfin, ça a été révélateur d'un bug). On réutilisait un code de correction d'erreur (c'était un système embarqué fort exposé aux rayonnements, donc beaucoup de bit flip) qui faisait simplement, à la réception de l'interruption "erreur détectée" un load et un store de l'adresse qui avait généré l'erreur (il y avait un système d'EDAC dans l'électronique qui nous corrigeait la valeur quand on loadait, et donc on restaurait la bonne valeur lors du store) Et ce code, qui était une réutilisation de code qui marchait, nous a provoqué une belle erreur sur un load non aligné…
ldsb address, reg # avec address pas multiple de 4
# --> EDAC, du à un SEU quelque part entre address, donc interruption
# gestion de l'interruption
[...]
ld address, reg # boum interruption, adresse non alignée, alors qu'on est dans une trap
nop
st reg, address
[...]
(la correction c'est de modifier l'adresse pour l'aligner sur un multiple de 4 dans la gestion de l'interruption, mais c'était du code qui existait depuis longtemps, et jusque là ça ne s'était jamais produit… enfin c'était un bug intéressant à comprendre, c'est juste dommage que ça se produise quand le machin était déjà lancé)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Méthodes de développement
Posté par 2PetitsVerres (Mastodon) . En réponse au journal De l'inéluctable progrès de l'informatique, ou pas.. Évalué à 2.
Ça dépend. Ton compilateur peut très bien décider de mettre son char sur 4 octets, parce qu'il pensera que ce sera plus rapide (et de ce que tu lui demandes). Du coup il ne perdra pas de temps. Et il ne gagnera pas de place en mémoire non plus. Par contre, sur d'autres architectures (je ne connais pas bien x86, à ce niveau) il y a des instructions de load non alignées, qui prennent le même temps qu'un load aligné, si je ne me trompe pas. Du coup tu peux gagner de la place sans perdre en performance. Mais c'est plutôt à réserver aux applications où tu en as vraiment besoin, ou éventuellement aux tableaux. Tu ne gagnes globalement rien si tu passes 42 int en char dans tout ton programme. (dans un précédent projet, on avait une table de calibration composée de 2*4*27*27 char si je me rappelle bien. Et 4Mo de RAM, 2Mo de ROM. La différence entre char et int (de 4 octets) c'est 17 ko, presque 1% de la ROM, 0.5% de la RAM.
Pour un exemple de load non aligné, il y a par exemple
sur sparc.
Faut faire quand même faire attention, ça peut avoir des effets ailleurs (enfin, ça a été révélateur d'un bug). On réutilisait un code de correction d'erreur (c'était un système embarqué fort exposé aux rayonnements, donc beaucoup de bit flip) qui faisait simplement, à la réception de l'interruption "erreur détectée" un load et un store de l'adresse qui avait généré l'erreur (il y avait un système d'EDAC dans l'électronique qui nous corrigeait la valeur quand on loadait, et donc on restaurait la bonne valeur lors du store) Et ce code, qui était une réutilisation de code qui marchait, nous a provoqué une belle erreur sur un load non aligné…
(la correction c'est de modifier l'adresse pour l'aligner sur un multiple de 4 dans la gestion de l'interruption, mais c'était du code qui existait depuis longtemps, et jusque là ça ne s'était jamais produit… enfin c'était un bug intéressant à comprendre, c'est juste dommage que ça se produise quand le machin était déjà lancé)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.