Le mardi 03 août, à 23h25 (+0200), Francois-Xavier KOWALSKI a écrit :
> Edgar> short inverse_short(short x)
> Edgar> {
> Edgar> return x<<8 & 0xff00 | x>>8 & 0xff;
> Edgar> }
>
> 1) Si x est un vrai short comme je l'entends (16 bits signés), le
> "x>>8 & 0xff" peut-etre replacé par un "x>>8" tout simple. Je ne
> suis pas sûr qu'un compilo touve celà tout seul.
Non, ça ne marche pas. Quand tu fais un décalage à droite sur un entier
signé, comme dans x>>8, l'espace libéré à gauche est souvent rempli avec
le bit de signe (le bit le plus à gauche). C'est ce qu'on appelle un
décalage arithmétique (ASR = « arithmetical shift right » dans
l'assembleur du 6502). Le K&R dit qu'en fait cela dépend de
l'implémentation, mais ça marche comme ça sur les machines sur
lesquelles j'ai essayé (Linux/Sparc, HP-UX/HP-PA, SunOS/Sparc, IRIX/SGI,
je n'ai pas de Lintel sous la main).
En revanche, le décalage est bien un décalage logique (LSR, remplissage
avec des zéros) si tu le fais sur un nombre non signé.
Si tu veux éliminer une opération, c'est probablement le « & 0xff00 »
qui ne sert à rien, puisque le résultat final sera converti en short.
> 2) Je suppose qu'une opération -- si simple soit-elle (comme le
> chargement d'un registre depuis la mémoire, ou le ET bit-à-bit) --
> est plus rapide sur un octet que sur un short.
Ce n'est pas du tout évident. S'il y a une taille d'entiers pour
laquelle c'est plus rapide c'est probablment le int qui est en fait la
taille « naturelle » des entiers de la machine. Une machine RISC doit en
principe faire les opérations élémentaires sur les int en un cycle
horloge.
> Je suggère donc "(x & 0xff) << 8" en lieu et place de "x<<8 &
> 0xff00".
Si tu veux, mais là tu travailles sur des ints et non sur des octets :
0xff est un int ;
int & int donne int ;
int << int donne int.
Si tu ne vois pas pourquoi 0xff est un int, je te renvoie au K&R,
page 191 de la 2e édition en français :
« Si [une constante entière] est octale ou hexadécimale et ne
comporte pas de suffixe, son type est le premier des types
suivants dans laquelle elle peut être représentée : int,
unsigned int, long int, unsigned long int. »
> 3) Simple remarque de codeur: Je suis surpris que le compilo ne
> s'insurge pas à la lecture d'une expréssion comportant somme toute
> pas mal d'opérateurs, pour bien peu de parenthèses...
Ayant goûté à une calculatrice HP en RPN dans ma jeunesse, je n'aime pas
trop les parenthèses. Toujours le K&R, à la page 53 on trouve le tableau
des priorités des opérateurs. Je l'ai photocopié et scotché sur le bord
de mon moniteur ;-).
--
Edgar Bonet Orozco
Lab. Louis Néel -- CNRS Tel : +33 476-88-90-89
BP 166 Fax : +33 476-88-11-91
38042 Grenoble cedex 9 e-mail : bonet@???
