Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
L'idée étant de pouvoir exécuter du code sur une de ces plateformes
(soit directement si on trouve du matos abordable, soit en l'émulant si
c'est possible) pour tester sa portabilité.
Le lundi 21 Octobre 2013 à 13:52 par Manuel Pégourié-Gonnard :
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en lien avec le langage C, mais comme il s'agit de portabilité qui est un des objectifs du C, et que la question ne se poserait pas dans d'autres langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne respectant pas certaines conditions d'alignement (par exemple, accès à un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais, uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
L'idée étant de pouvoir exécuter du code sur une de ces plateformes (soit directement si on trouve du matos abordable, soit en l'émulant si c'est possible) pour tester sa portabilité.
Merci d'avance !
-- Manuel Pégourié-Gonnard
Bonjour cher emprunteurs, pour toute personne désireuse acquérir une certaine somme d'argent pour un but précis, je propose mon soutien financier à toute personne solvable. Ayant fait un important dépôt en banque, je suis dans la possibilité de prêter entre 50000 euros à 300 000 euros. PS: Offre rapide et engagement sur rencontre. mail :
Le lundi 21 Octobre 2013 à 13:52 par Manuel Pégourié-Gonnard :
Bonjour,
Je suis désolé de poster ici une question qui n'est que
marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès
mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès
à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je
sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
L'idée étant de pouvoir exécuter du code sur une de ces
plateformes
(soit directement si on trouve du matos abordable, soit en l'émulant si
c'est possible) pour tester sa portabilité.
Merci d'avance !
--
Manuel Pégourié-Gonnard
Bonjour cher emprunteurs, pour toute personne désireuse acquérir une certaine somme d'argent pour un but précis, je propose mon soutien financier à toute personne solvable.
Ayant fait un important dépôt en banque, je suis dans la possibilité de prêter entre 50000 euros à 300 000 euros. PS: Offre rapide et engagement sur rencontre. mail : lasagesse00@gmail.com
Le lundi 21 Octobre 2013 à 13:52 par Manuel Pégourié-Gonnard :
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en lien avec le langage C, mais comme il s'agit de portabilité qui est un des objectifs du C, et que la question ne se poserait pas dans d'autres langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne respectant pas certaines conditions d'alignement (par exemple, accès à un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais, uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
L'idée étant de pouvoir exécuter du code sur une de ces plateformes (soit directement si on trouve du matos abordable, soit en l'émulant si c'est possible) pour tester sa portabilité.
Merci d'avance !
-- Manuel Pégourié-Gonnard
Bonjour cher emprunteurs, pour toute personne désireuse acquérir une certaine somme d'argent pour un but précis, je propose mon soutien financier à toute personne solvable. Ayant fait un important dépôt en banque, je suis dans la possibilité de prêter entre 50000 euros à 300 000 euros. PS: Offre rapide et engagement sur rencontre. mail :
Manuel Pégourié-Gonnard
Bonjour,
je reviens un peu tardivement sur ce fil, d'une part pour remercier tous ceux qui ont répondu pour leurs réponses (désolé de ne pas l'avoir fait plus tôt), d'autre part pour résumer un peu.
Manuel Pégourié-Gonnard scripsit :
Qu'y a-t-il comme architecture courante où les accès mémoire ne respectant pas certaines conditions d'alignement (par exemple, accès à un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais, uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
On a donc : MIPS, SPARC, alpha, 68000 (mais seulement les originaux).
L'idée étant de pouvoir exécuter du code sur une de ces plateformes (soit directement si on trouve du matos abordable, soit en l'émulant si c'est possible) pour tester sa portabilité.
D'après mes tests, l'émulation par Qemu de MIPS n'est pas fidèle sur ce point, je peux faire des accès non alignés sans recevoir de SIGBUS dans un programe tournant sous qemu-mips. Donc ce n'est pas une option viable pour tester.
Sur x86(-64), au moins sous Linux et FreeBSD, il suffit d'armer le bit AC (bit 18) du registre EFLAGS (resp. RFLAGS) pour forcer la vérification de l'alignement, car le bit AM du registre CR0 est déjà armé par l'OS. Néanmoins, mes test (sous Linux) confirment ce qu'annonçait Jean-Marc : la bibli standard fait plein d'accès non alignés, donc ce n'est pas pratique pour tester non plus.
Par ailleurs, j'ai découvert qu'il y a un mécanisme vaguement similaire sur ARM/linux, en passant par un réglage du noyau [1]. Je n'ai pas encore eu l'occasion de tester pour voir si c'est utilisable en pratique. (L'inconvénient évident semble être que ça s'applique à tous les processus en espace utilisateur, et non pas au processus individuel qu'on aimerait tester.)
Au final, je vais sans doute utiliser le petit routeur que je viens de recevoir (basé sur une puce MIPS) pour ces tests, dès que j'aurai eu/pris le temps d'installer OpenWRT dessus et d'apprivoiser le processus de cross-compilation.
Encore merci pour vos réponses et désolé d'y réagir si tardivement.
Manuel.
Bonjour,
je reviens un peu tardivement sur ce fil, d'une part pour remercier tous
ceux qui ont répondu pour leurs réponses (désolé de ne pas l'avoir fait
plus tôt), d'autre part pour résumer un peu.
Manuel Pégourié-Gonnard scripsit :
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
On a donc : MIPS, SPARC, alpha, 68000 (mais seulement les originaux).
L'idée étant de pouvoir exécuter du code sur une de ces plateformes
(soit directement si on trouve du matos abordable, soit en l'émulant si
c'est possible) pour tester sa portabilité.
D'après mes tests, l'émulation par Qemu de MIPS n'est pas fidèle sur ce
point, je peux faire des accès non alignés sans recevoir de SIGBUS dans
un programe tournant sous qemu-mips. Donc ce n'est pas une option
viable pour tester.
Sur x86(-64), au moins sous Linux et FreeBSD, il suffit d'armer le bit
AC (bit 18) du registre EFLAGS (resp. RFLAGS) pour forcer la
vérification de l'alignement, car le bit AM du registre CR0 est déjà
armé par l'OS. Néanmoins, mes test (sous Linux) confirment ce
qu'annonçait Jean-Marc : la bibli standard fait plein d'accès non
alignés, donc ce n'est pas pratique pour tester non plus.
Par ailleurs, j'ai découvert qu'il y a un mécanisme vaguement similaire
sur ARM/linux, en passant par un réglage du noyau [1]. Je n'ai pas
encore eu l'occasion de tester pour voir si c'est utilisable en
pratique. (L'inconvénient évident semble être que ça s'applique à tous
les processus en espace utilisateur, et non pas au processus individuel
qu'on aimerait tester.)
Au final, je vais sans doute utiliser le petit routeur que je viens de
recevoir (basé sur une puce MIPS) pour ces tests, dès que j'aurai
eu/pris le temps d'installer OpenWRT dessus et d'apprivoiser le
processus de cross-compilation.
Encore merci pour vos réponses et désolé d'y réagir si tardivement.
je reviens un peu tardivement sur ce fil, d'une part pour remercier tous ceux qui ont répondu pour leurs réponses (désolé de ne pas l'avoir fait plus tôt), d'autre part pour résumer un peu.
Manuel Pégourié-Gonnard scripsit :
Qu'y a-t-il comme architecture courante où les accès mémoire ne respectant pas certaines conditions d'alignement (par exemple, accès à un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais, uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
On a donc : MIPS, SPARC, alpha, 68000 (mais seulement les originaux).
L'idée étant de pouvoir exécuter du code sur une de ces plateformes (soit directement si on trouve du matos abordable, soit en l'émulant si c'est possible) pour tester sa portabilité.
D'après mes tests, l'émulation par Qemu de MIPS n'est pas fidèle sur ce point, je peux faire des accès non alignés sans recevoir de SIGBUS dans un programe tournant sous qemu-mips. Donc ce n'est pas une option viable pour tester.
Sur x86(-64), au moins sous Linux et FreeBSD, il suffit d'armer le bit AC (bit 18) du registre EFLAGS (resp. RFLAGS) pour forcer la vérification de l'alignement, car le bit AM du registre CR0 est déjà armé par l'OS. Néanmoins, mes test (sous Linux) confirment ce qu'annonçait Jean-Marc : la bibli standard fait plein d'accès non alignés, donc ce n'est pas pratique pour tester non plus.
Par ailleurs, j'ai découvert qu'il y a un mécanisme vaguement similaire sur ARM/linux, en passant par un réglage du noyau [1]. Je n'ai pas encore eu l'occasion de tester pour voir si c'est utilisable en pratique. (L'inconvénient évident semble être que ça s'applique à tous les processus en espace utilisateur, et non pas au processus individuel qu'on aimerait tester.)
Au final, je vais sans doute utiliser le petit routeur que je viens de recevoir (basé sur une puce MIPS) pour ces tests, dès que j'aurai eu/pris le temps d'installer OpenWRT dessus et d'apprivoiser le processus de cross-compilation.
Encore merci pour vos réponses et désolé d'y réagir si tardivement.
