Discussion :

[Lulu_n10]

Bonjour, voici mon code, je comprend pas pourquoi le cmp ebx,'A' ne fonctionne pas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
global main
 
extern printf
extern scanf
extern malloc
extern free
extern fopen
extern fclose
extern fscanf
extern fgets
 
section .data
	SIZE EQU 256
	buffer times SIZE db 0
	c dd 0
	com db 'A'
	_in_ dd 0
	opening_mode db "r",0
	nom_fichier db "val.txt",0
	msg db "valeur:%s",10,0
	msg_testc db "car:%c",10,0
	msg_vect db "[%f, %f, %f, %f]",10,0
	msg_fscanf db "%c",10,0
	msg_com db "ceci est un commentaire",10,0
	msg_test db "bug",10,0
	struc Vector
		v_1: resd 1
		v_2: resd 1
		v_3: resd 1
		v_4: resd 1
		v_suivant: resd 1
	endstruc
section .text
 
;------------------------------------------------------------------------------------------------------------------------------
traite_fichier:
	push ebp
	mov ebp,esp
	push dword [_in_]
	push dword SIZE
	push dword buffer
	call fgets
	add esp,12
 
	push dword buffer
	push dword msg
	call printf
	mov ebx,[buffer]
	push dword ebx
	push dword msg_testc
	call printf
 
	cmp ebx,'A'
	jne .endcom
	push dword msg_com
	call printf
	jmp .endcom2
.endcom:
	push dword msg_test
	call printf
.endcom2:
	mov esp,ebp
	pop ebp
	ret
;------------------------------------------------------------------------------------------------------------------------------
main:
	push ebp
	mov ebp,esp
	pushad
	push dword opening_mode
	push dword nom_fichier
	call fopen
	add esp,8
	mov [_in_],eax
	cmp eax,0
	je .end
	call traite_fichier
 
.end:
 
	popad
	mov esp,ebp
	pop ebp

[Forthman]

Hello,

Rapidement, comme ça sur le feu...

EBX = 32 bits
"A" = 8 bits

a+ François

[- Robby -]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
mov ebx,[buffer]
push dword ebx
push dword msg_testc
call printf
 
cmp ebx,'A'
jne .endcom

"ebx" 32bits, 'A' 8bits ... ça, c'est pas grave, le compilateur agira par extension. "Buffer" comme je vois, étant un tableau de bytes, il est fort probable que le "mov ebx,[buffer]" générera un "movzx".
Et le "cmp" se fera sur une valeur de 'A' étendue à 32bits.
Par conre,
Quel est la valeur de "ebx" après un appel à la fonction "printf" ?
Le registre "ebx" est initialisé "avant" l'appel ...
mais qui dit que la fonction "printf" ne modifie pas ce registre en sortie ?
perso ... je ferais ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
mov ebx,[buffer]
push ebx
push dword ebx
push dword msg_testc
call printf

pop ebx
cmp ebx,'A'
jne .endcom

[Forthman]

Oui mais non,

La comparaison avec "A" porte sur quelle partie de EBX ?
Le compilo va compléter les octets manquants par quoi ? (valeur 00h j'imagine)

Si c'est le dernier octet de EBX qui compte, il fait un cmp bl,"A"
sinon il fait un ROR ou un SHR

a+ François

[- Robby -]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cmp ebx , 'A'

donnera après compilation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cmp ebx , 00000041h ... (32bits des 2 côtés)

et le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mov ebx , [buffer] .... qui est  un tableau de bytes

donnera après compilation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

movzx ebx , byte ptr [buffer]

byte ptr [buffer] sera chargé dans "bl"
et ebx sera "étendu" par des zéro" (c'est le but de movzx)

[dapounet]

Bonsoir,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mov ebx , [buffer] .... qui est  un tableau de bytes

donnera après compilation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

movzx ebx , byte ptr [buffer]

byte ptr [buffer] sera chargé dans "bl"
et ebx sera "étendu" par des zéro" (c'est le but de movzx)

Je miserais plutôt sur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mov ebx, dword[buffer]

Je n'ai pas le temps maintenant mais je vérifie demain.

[- Robby -]

salut Dapounet,

bein écoute, je programme sous Visual C++ express 2008,
dans lequel je fais pas mal d'asm en ligne,
J'utilise aussi le WDK (drivers) et son compilo intégré

j'ai essayé les 2, et les 2 me refusent la compilation
error C2443: operand size conflict (bein oui !)

ceci dit, le compilo de Visual C++ express, celui de Visual Studio et celui du WDK ...
c'est le même compilateur C (qui permet l'asm en ligne).

Si un compilateur accepte ... MASM peut être ?
Il y a un confit de type, un cast est obligatoire.
et en toute logique le "movzx" me semblait incontournable.
Mais là ... faut un compilo qui pense plus loin que l'bout de son nez

je suis curieux de voir "tes" résultats,
et avec quel compilo tu auras testé ça.
tu as peut être raison !

[Forthman]

Moi je trouve pas très logique de mélanger du 8, 16 et 32 bits et de dire
que le compilo va résoudre le problème tout seul...

M'enfin, ce n'est que mon avis, et je suis pas un pro

a+ François

[- Robby -]

logique ? non, en effet.
mais c'est pourtant ce que LuLu a fait en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mov ebx,[buffer]

ce, dans le code qu'il propose.
Et apparemment, il a "réussi" à compiler.

La logique aurait été de, soit

a) faire référence à un tableau de "dword"

b) soit utiliser directement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
movzx ebx , [buffer]
ou
mov bl , [buffer] (et adapter le reste du code)

Moi, je me demande :

Quel code réel a généré "sa" compilation ?
et quel compilateur a-t-il utilisé ?

[Forthman]

Bien je ne vois pas pourquoi le compilo aurait empêché :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 mov ebx,[buffer]

Ce n'est pas parce qu'une zone mémoire est réservée en octets
qu'on ne peut pas y accéder par doubles mots

dans ce cas, ebx contient les 4 premiers octets de son buffer

a+ François

[- Robby -]

Dans "l'absolu" microprocesseur ... oui, bien entendu !

Mais ici, tu ne dialogues pas avec le processeur, mais avec le compilo.
Et un compilateur est un peu "plus" qu'un truc qui retranscrit
bêtement du mnémonique en code machine.

Le compilateur s'aperçoit que l'on "demande" de charger un "dword"
au départ d'une zône mémoire déclarée comme une suite de bytes.
Et pour lui, cette "demande" est incohérente.

et parceque franchement, avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mov ebx , [buffer]

le compilateur ne sait "pas" ce qu'il doit faire !
Buffer ne représente pas une adresse explicite, c'est un symbol.

le minimum pour lever le questionnement du compilo,
lui demander de ne pas tenir compte de la "déclaration" de buffer en bytes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mov ebx , dword ptr [buffer] .... là, pas de soucis, ça compile !

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
mov eax , offset buffer
mov ebx , [eax]

là, pas d'incertitude non plus pour le compilo, la demande est sans équivoque.

En tout cas, le compilateur du WDK et de Visual Studio de Microsoft,
compilateur C ... mais qui accepte sans aucun soucis l'assembleur,
refuse la compilation de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mov ebx , [buffer] ... buffer tableau de bytes

Il signale une erreur de type.

Maintenant, fort possible que d'autres compilos soient plus "souples"
Je pense à MASM ... (que je ne connais pas)

Mais dans ce cas, le "mnémonique" n'étant pas parfaitement explicite,
le code généré deviendrait quasi alléatoire, et "propre" au compilo !
car ... les interprétations sont multiples !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
mov ebx , dword ptr [buffer]
movzx ebx , [buffer]
 
et pourquoi pas :
 
mov bl , [buffer]
 
bein oui, si on essaye de "lever" l'incohérence ... pourquoi pas !
 
à l'appréciation du compilo !!!

[Forthman]

Ok.

merci pour ces explications

a+ François

[dapounet]

Bonjour,

Lulu_n10 utilise sûrement NASM, et ce n'est pas l'assembleur le plus malin pour gérer les symboles.

Par exemle il refuse ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
section .data
  var dd 0
 
section .text
  mov [var], 42 ; error: operation size not specified

Parce que dès que la variable a été créée, NASM a oublié son taille.
FASM et MASM la retiennent, mais à ma connaissance ils ne s'en servent que quand il n'y a pas d'autre information sur la taille des oérandes.