Bonjour.
A mes moments perdus, j'étudie le livre de Kip Irvine sur le Masm : Assembleur x86.
A la p. 174, il présente une procédure ReadInt de sa bibliothèque Irvine32.lib, qui lit (après saisie) un entier signé stockable sur 32 bits; si la saisie ne peut pas être stockée de cette façon, la procédure affiche un message d'erreur et, théoriquement, arme le drapeau Overflow.
J'ai l'impression qu'en fait, elle n'arme pas ce drapeau. Cela me semble résulter de l'exécution du programme suivant (solution de l'exercice 3 du chapitre 6, p. 255) :
TITLE Evaluation d'un résultat de test. (MonExamen.asm)
; Description : ma solution de l'exercice d'Irvine, ch. 6,
; exerc. 3, p. 255. L'utilisateur introduit un score et le programme affiche la
; cote littérale correspondante.
; Auteur :
; Date de création : 8 décembre 2004.
INCLUDE Irvine32.inc
.data
zerosigne SDWORD 0 ; pour éviter la comparaison d'un
; registre et de la valeur immédiate
; nulle.
; (Je ne sais pas si cette comparaison
; est permise et, à supposer qu'elle le
; soit, je suppose que les entiers
; comparés sont alors supposés non
; signés, cfr. p. 250 pour la
; comparaison de deux registres.)
cent SDWORD 100 ; idem. (Eviter la comparaison d'un
; registre et d'une valeur immédiate.)
prompt1 BYTE "Saisissez un entier de 0 ", 133, "100 : ", 0
prompt2 BYTE "L'entier que vous saisissez doit aller de 0 ", 133, " 100. Il ne peut pas ", 136, "tre n", 130, "gatif. Recommencez.", 0
prompt3 BYTE "Ce que vous avez saisi n'est pas stockable comme entier sign", 130, " sur 32 bits. Le programme se termine. Dans une version future, il vous permettra peut-", 136, "tre de recommencer.", 0
promptA BYTE "A", 0
promptB BYTE "B", 0
promptC BYTE "C", 0
promptD BYTE "D", 0
promptF BYTE "F", 0
entierlu SDWORD ? ; Ceci aussi servira à forcer
; une comparaison entre entiers signés.
.code
main PROC
mov edx, OFFSET prompt1
call WriteString ; affiche la chaîne stockée à l'adresse
; contenue dans edx. (Bibl. Irvine.inc)
or eax, 0 ; désarme Overflow, ce qui permettra de
; savoir si l'instruction suivante
; (ReadInt) échoue. (Méthode indiquée
; p. 218.)
call ReadInt ; Voir Irvine p. 174.
; Lit un entier signé sur 32 bits
; et le renvoie vers eax. Affiche un
; message d'erreur et arme Overflow si
; la saisie ne peut être stockée comme
; entier signé sur 32 bits.
; EN FAIT, ON DIRAIT QUE, DANS LE CAS
; OU LA SAISIE NE PEUT PAS ETRE STOCKEE
; COMME ENTIER SIGNE SUR 32 BITS,
; READINT N'ARME PAS OVERFLOW. VOIR
; PLUS LOIN.
; Ce qui suit est pour mes essais.
call DumpRegs ; Rappel : DumpRegs est une procédure de la
; bibliothèque Irvine32.lib. Elle affiche
; le contenu de certains registres
; (notamment le drapeau Overflow) aux fins
; de débogage (p. 171). Je suppose donc
; qu'elle ne modifie pas les registres.
; Si on fait lire par ReadInt un nombre
; trop grand, elle devrait armer le
; drapeau Overflow (Irvine, p. 174),
; mais ce DumpRegs
; montre qu'elle ne l'arme pas !!!!!!!!
;;;;;;;;;;
jo mauvaisentier ; saute si ReadInt a armé le drapeau
; Overflow. (Mais comme noté, il me
; semble qu'il y a un bug : elle n'arme
; jamais ce drapeau...)
.WHILE (eax < zerosigne) || (eax > cent)
mov edx, OFFSET prompt2
call WriteString
or eax, 0 ; Voir plus haut.
call ReadInt
jo mauvaisentier ; Voir plus haut.
.ENDW
mov entierlu, eax ; Pour forcer la comparaison entre
; entiers signés.
.IF entierlu >= 90
mov edx, OFFSET promptA
call WriteString
.ELSEIF entierlu >= 80
mov edx, OFFSET promptB
call WriteString
.ELSEIF entierlu >= 70
mov edx, OFFSET promptC
call WriteString
.ELSEIF entierlu >= 60
mov edx, OFFSET promptD
call WriteString
.ELSE
mov edx, OFFSET promptF
call WriteString
.ENDIF
jmp quitter
mauvaisentier:
mov edx, OFFSET prompt3
call WriteString
quitter:
exit ; Retour au système d'exploitation. (Défini dans
; Irvine32.inc.)
main ENDP
END main
Quelqu'un peut-il me dire s'il y a réellement quelque chose qui cloche dans la procédure ReadInt d'Irvine ou si c'est moi qui me trompe ?
Merci d'avance.
P.S. Les commentaires du programme montrent que la comparaison d'un registre et d'une valeur immédiate me pose un problème, mais c'est une autre affaire.
Panurge.
Message édité par Panurge le 10-12-2004 à 17:43:00