accès non alignés
Le
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
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
sparc, 68000 je crois.
--
Les simplifications c'est trop compliqué
Erwan David
Bonjour,
MIPS, Alpha (mais c'est mort) et en règle générale les processeurs
RISC qui aiment assez les BUS ERROR.
Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait d'exécuter la
séquence au début du programme.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Il y a bien un mode qui permet de faire ca. De memoire, il etait
impossible a utiliser en pratique parce que la lib standard et les
autres lib de l'OS utilisent les acces non alignes donc foirent
joyeusement meme si ton code n'a pas de probleme.
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pour les 68000, il faut du vrai 68000 de base. Il me semble qu'il y a de
quoi gerer les acces non alignes des le 6820...
Si tu veux de la portabilite, utilise uint_least32_t. Lui, il est *garanti*
par la norme (et il vaut exactement uint32_t si ce dernier existe).
Il faut armer le bit 18 du registre eflags. Une telle séquence peut
être (sous gcc, ou sous clang) :
__asm__("pushfnorl $0x40000,(%esp)npopf");
On peut aussi désactiver cette fonctionalité avant appel
à certaines bibliothèques, en désarmant ce bit :
__asm__("pushfnandl $0xfffbffff,(%esp)npopf");
Pour un x86_64, il suffit de remplacer %esp par %rsp, et
de pas oublier que l'on récupère sur la pile le registre
rflags (64 bits) et non plus eflags (32 bits).
Pour armer :
__asm__("pushfnorl $0x40000,(%rsp)npopf");
et pour désarmer :
__asm__("pushfnandl $0xfffffffffffbffff,(%rsp)npopf");
Bien sûr, ce genre de pratique ne vaut que si l'on a pas un
bon vieux sparc sous la main, et que l'on désire vérifié
qu'un bout de code sera correct d'un point de vue alignement.
A plus,
--
Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Il faut aussi que le processeur soit dans le mode où cela a un effet,
c'est-à-dire que le bit 18 (AM, même place) du registre CR0 soit armé.
En toute logique, pour un système normal le bit CR0.AM devrait être
désarmé, sinon c'est trop facile pour du code utilisateur de créer un
piège système imparable (ou à tout le moins de forcer un détour par
l'INT 0x17 à chaque accès mémoire). Et tout aussi logiquement, l'accès à
CR0 est réservé au système (ring 0, kernel, etc.)
Antoine
De mémoire, le 68000 génère une exception quand cela se produit. Le
système, s'il le souhaite, peut détourner le vecteur d'interruption
correspondant et faire les corrections nécessaires pour que cela
fonctionne de manière transparente. C'est plus lent (interruption +
accès multiples), mais c'est possible et c'est donc un problème
logiciel. Après, tout dépend de l'implémentation et de ses objectifs
(stabilité ou efficacité), etc...
--
Alexandre
Pas pour tous les process. Uniquement pour ceux qui auront
armé le bit AM du registre EFLAGS.
En ce cas, l'interruption logicielle aura pour unique conséquence
l'envoie d'un sig bus au process fautif, si effectivement
l'OS aura pris soin d'armé le bit AM du registre CR0, ce qui est
d'ailleurs le cas sous FreeBSD et Linux.
Et heureusement.
--
Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
De mémoire (c'est trèèèèès loin pour moi) le 68000 de base ne sait pas
reprendre complètement une instruction interrompue, ce qui complique
notablement ce genre de procédure. Avec un 68010, par contre, ce doit
être possible (et long, et pas souvent implanté dans le système).
Antoine
Oui, ca me rappelle egalement des choses. Je suis a peu pres certain que
tu as raison.