Corrigé du TP 3 : Manipulation de la pile

Variables locales/globales

Pile.c

Pile.s

/* Déclaration des variables globales */
char a,b;
unsigned char c,d;
short e;
unsigned short f;
short g;
int h,i;
long j;
double k;
int main()
{
/* Déclaration des variables locales */
char ma,mb;
unsigned char mc;md;
short me = 12;
unsigned short mf;
short mg;
int mh,mi;
long mj;
double mk=2,5;
/* Quelques instructions quand même... */
a=ma; b=mb; c=mc; d=md; e=me; f=mf;
g=mg; h=mh; i=mi; j=mj; k=mk;
g=-5;
return 0;
}

LC0:
.long 0, 1074003968 ; 10000000000010...0b (40 bits à 0)
.text
.globl main
main:
pushl %ebp
movl %esp, %ebp
subl $40, %esp ; allocation de 40 octets sur la pile
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
movw $12, -6(%ebp) ; me <= 12
fldl LC0 ; charge LC0..LC0+7 dans le coprocesseur
fstpl -32(%ebp) ; mk <= valeur flottante (coprocesseur)
movzbl -1(%ebp), %eax ; eax <= ma (1 octet), remplissage avec 24x0
movb %al, a
movzbl -2(%ebp), %eax ; eax <= mb (1 octet), remplissage avec 24x0
movb %al, b
movzbl -3(%ebp), %eax ; eax <= mc (1 octet), remplissage avec 24x0
movb %al, c
movzbl -4(%ebp), %eax ; eax <= md (1 octet), remplissage avec 24x0
movb %al, _d
movzwl -6(%ebp), %eax ; eax <= me (2 octets), remplissage avec 16x0
movw %ax, e
movl -8(%ebp), %eax ; eax <= mf (2 octets), lecture de 32 bits
movw %ax, f
movzwl -10(%ebp), %eax ; eax <= mg (2 octets), remplissage avec 16x0
movw %ax, g
movl -16(%ebp), %eax ; eax <= mh (4 octets)
movl %eax, h
movl -20(%ebp), %eax ; eax <= mi (4 octets)
movl %eax, i
movl -24(%epp), %eax ; eax <= mj (4 octets)
movl %eax, j
fldl -32(%ebp) ; coprocesseur <= mk (8 octets)
fstpl k ; k <= coprocesseur (8 octets)
movw $-5, g
movl $0, %eax
leave
ret
;réservation des variables globales
.comm a, 16 # 1
.comm b, 16 # 1
.comm c, 16 # 1
.comm d, 16 # 1
.comm e, 16 # 2
.comm f, 16 # 2
.comm g, 16 # 2
.comm h, 16 # 4
.comm i, 16 # 4
.comm j, 16 # 4
.comm k, 16 # 8

Contenu de la mémoire :

- 32	- 31	- 30	- 29	- 28	- 27	- 26	- 25	- 24	- 23	- 22	- 21	- 20	- 19	- 18	- 17	- 16	- 15	- 14	- 13	- 12	- 11	- 10	- 9	- 8	- 7	- 6	- 5	- 4	- 3	- 2	- 1	ebp
mk								mj				mi				mh						mg		mf		me		md	mc	mb	ma

Vous noterez que les variables globales a...k sont situées en dehors de la pile, sur le tas statique.
La directive .comm réserve en effet de la mémoire dans le segment de données et lui attribue un nom (une étiquette).

Noter le trou situé entre mg et mh, aux adresses ebp-12 et ebp-11.
C'est une optimisation faite par GCC pour aligner mh, mi, mj et mk sur des mots-mémoire de 32 bits.
En effet, le 80386 a un bus de données de 32 bits. Il lit donc de toute façon 32 bits simultanément.
Lire 32 bits à partir de l'adresse 18 demanderait donc deux accès successifs : de 16 à 19, puis de 20 à 23.

Concernant la représentation des données en mémoire, le programme mentionne trois constantes 12, -5, et 2.5.
12 se traduit naturellement par la valeur 12... soit 0000 0000 0000 0000 0000 0000 0000 1100₂.
-5 se traduit par 0xFFFB, soit 1111 1111 1111 1011₂. Ce qui donne, en complément à 2 : compl(1..1 1011 - 1) = 0..0 0101₂ = 5.
2.5 se traduit par 0100 0000 0000 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000₂. Soit :

Signe (1 bit) = 0 : valeur positive.
Exposant (11 bits) = 100 0000 0000₂ : e=1024=E+1023 => E=1 (Exposant biaisé)
Mantisse (52 bits) = 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000₂ : M = (1) ,010..0₂
(premier bit toujours à 1, donc non exprimé.)
Valeur = S M*2^E = + 1,01₂*2¹ = 10,1₂ = 2,5₁₀.

Pile_.c

Pile_.s

/* Déclaration des variables globales */
char a;
short e;
unsigned short f;
short g;
char b;
int h;
unsigned char c;
long j;
unsigned char d;
double k;
int i;
int main()
{
/* Déclaration des variables locales */
char ma;
short me;
unsigned short mf;
short mg;
char mb;
int mh;
unsigned char mc;
long mj;
unsigned char md;
double mk;
int mi;
/* Quelques instructions quand même... */
a=ma; b=mb; c=mc; d=md; e=me; f=mf;
g=mg; h=mh; i=mi; j=mj; k=mk;
return 0;
}

.text
.globl main
main:
pushl %ebp
movl %esp, %ebp
subl $56, %esp ; allocation de 56 octets sur la pile
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
movzbl -1(%ebp), %eax ; eax <= ma (1 octet), remplissage avec 24x0
movb %al, a
movzbl -9(%ebp), %eax ; eax <= mb (1 octet), remplissage avec 24x0
movb %al, b
movzbl -17(%ebp), %eax ; eax <= mc (1 octet), remplissage avec 24x0
movb %al, c
movzbl -25(%ebp), %eax ; eax <= md (1 octet), remplissage avec 24x0
movb %al, d
movl -4(%ebp), %eax ; eax <= me (2 octets), remplissage avec 16x0
movw %ax, e
movzwl -6(%ebp), %eax ; eax <= mf (2 octets), lecture de 32 bits
movw %ax, f
movl -8(%ebp), %eax ; eax <= mg (2 octets), remplissage avec 16x0
movw %ax, g
movl -16(%ebp), %eax ; eax <= mh (4 octets)
movl %eax, h
movl -44(%ebp), %eax ; eax <= mi (4 octets)
movl %eax, i
movl -24(%ebp), %eax ; eax <= mj (4 octets)
movl %eax, j
fldl -40(%ebp) ; coprocesseur <= mk (8 octets)
fstpl k ; k <= coprocesseur (8 octets)
movl $0, %eax
leave
ret
;réservation des variables globales
.comm a, 16 # 1
.comm e, 16 # 2
.comm f, 16 # 2
.comm g, 16 # 2
.comm b, 16 # 1
.comm h, 16 # 4
.comm c, 16 # 1
.comm j, 16 # 4
.comm d, 16 # 1
.comm k, 16 # 8
.comm i, 16 # 4

Contenu de la mémoire :

- 44	- 43	- 42	- 41	- 40	- 39	- 38	- 37	- 36	- 35	- 34	- 33	- 32	- 31	- 30	- 29	- 28	- 27	- 26	- 25	- 24	- 23	- 22	- 21	- 20	- 19	- 18	- 17	- 16	- 15	- 14	- 13	- 12	- 11	- 10	- 09	- 08	- 07	- 06	- 05	- 04	- 03	- 02	- 01	ebp
mi				mk															md	mj							mc	mh							mb	mg		mf		me			ma

On notait que GCC laisse un certain nombre de trous afin d'aligner les variables short sur des adresses paires, les variables int sur des adresses multiples de 4, et la variable double sur une adresse multiple de 8.

Ce comportement a changé avec les versions récentes de GCC. Il réordonne désormais les variables pour éviter un maximum de trous dans la pile...

Si l'on remplace les lignes int h et int mh respectivement par static int h et static int mh, on observe que la variable locale mh devient globale, c'est à dire située hors de la pile. Son nom devient alors mh.xyz avec xyz un entier aléatoire.De cette façon, sa valeur est conservée entre deux appels de la fonction.

Appel de fonctions

Pile2.c

Pile2.s

int a;
main2()
{
int b;
a = appel_fonction(b);
return 0;
}
main()
{
return main2();
}
int appel_fonction(int c)
{
int d;
d = c;
return(d);
}

.comm a,4,4 ; variable globale : a
.text
.globl main2
main2:
pushl %ebp
movl %esp, %ebp
subl $40, %esp ; allocation de 40 octets sur la pile
movl -12(%ebp), %eax
movl %eax, (%esp) ; appel_fonction.c <= eax = b
call appel_fonction
movl %eax, a ; a <= résultat(appel_fonction)
movl $0, %eax ; résultat(main) <= 0
leave
ret
.globl main
main:
; Cadre de pile de la fonction main... à ignorer
pushl %ebp
movl %esp, %ebp
andl $-16, %esp
call main2
leave
ret
.globl appel_fonction
appel_fonction:
pushl %ebp
movl %esp, %ebp
subl $16, %esp
movl 8(%ebp), %eax ; résultat(appel_fonction) = c
movl %eax, -4(%ebp)
movl -4(%ebp), %eax
leave
ret

Sachant que le compilateur C lit le programme de haut en bas (dans ce sens), il ne connait pas la fonction appel_fonction au moment où elle est appelée dans la fonction principale. Il suppose donc que son format est correct, et crée le profil correspondant. Il vérifiera alors les appels suivant en se basant sur ce profil.

Contenu de la mémoire à la ligne 40 (ligne 17 du C) :

...
	adresse de retour	Fonction main2
EBP_t-1	EBP_t-2(main)
	b




	c	Fonction appel_fonction	(Créé par main2)
	adresse de retour (= ligne 13)
EBP_t	EBP_t-1
ESP	d

On remarque que l'appel de la fonction main2 par la fonction main ne traduit pas le return. En effet, main2 stocke son résultat dans le registre eax. main doit également stocker son résultat dans le registre eax. Il faudrait donc écrire movl %eax, %eax, ce qui est totalement inutile. Le compilateur retire donc cette instruction. Intelligent, non ?

Optimisation de l'appel de fonctions

$gcc -S -O3 pile2.c -o pile2.opt.s

Pile2.c

Pile2.opt.s

int a;
main2()
{
int b;
a = appel_fonction(b);
return 0;
}
main()
{
return main2();
}
int appel_fonction(int c)
{
int d;
d = c;
return(d);
}

.text
.globl main2
main2:
; Pas de cadre de pile ici
movl $0, a ; La valeur de b est inconnue. pourquoi pas 0 ?
xorl %eax, %eax ;return 0;
ret
.globl main
main:
movl $0, a ; La valeur de b est inconnue. pourquoi pas 0 ?
xorl %eax, %eax ; return 0;
ret
.globl appel_fonction
appel_fonction:
; Pas de cadre de pile ici
movl 4(%esp), %eax
ret
.comm a,4,4 ; variable globale a

On constate que la version optimisée de ce programme ne contient plus les variables b et d. Le schéma mémoire se réduit donc aux deux cadres de piles... vides !

Et encore, on peut noter que la fonction appel_fonction n'est plus appelée du tout. GCC a fait ce que l'on nomme inlining : Il a copié-collé le contenu de la fonction dans main2 et dans main.
La fonction main se résume donc à remplir la variable a aléatoirement ( ici 0 ) et à retourner 0.

Les fonctions ne sont conservées que parce qu'elles sont publiques. Si un programme lie le fichier objet à d'autres, ces fonctions doivent exister sous peine d'erreur d'édition des liens...
Si on rend la fonction privée static int appel_fonction(int c), elle disparaît totalement du fichier objet et de son source assembleur associé...

Retour à la liste des TP