Ma bag si eu in discutie just for the fun of it. Iti spun de la
inceput ca nu prea suport compilatoarele C/C++ pentru ca pentru small
scale projects iti baga o gramada de magarii in plus, consumand
memorie si resurse aiurea. Exemplul de fata este unul dintre ele :
Din observatiile mele GCC tine toate variabilele multiplu de 4
aliniate la 4 bytes si pe cele care nu sunt multiplu de 4 aliniate la
16 bytes. Se presupune ca stiva este intotdeauna aliniata si se pleaca
de la inceputul programului cu ea aliniata.
Incearca si cu alte valori in loc de 3.
Uite rezultatele mele :
cu 15 = 24 bytes alocati
cu 17 = 40 bytes alocati (24 + 16)
cu 33 (17 + 16) = 56 bytes alocati (40 + 16)
si asa mai departe. De fiecare data, GCC a alocat cate 16 bytes chiar
si pentru un extra-byte care iesea din calculele exacte.
Acum, de ce se aloca inca de la inceput in primul pas 24 bytes nu stiu
exact. 24 = 16 + 8. Dupa cum se poate vedea mai sus, cum am trecut
pragul celor 16 bytes si am avut nevoie de 17 a sarit imediat la 40.
Deci el a alocat 16 bytes pentru cei 3 ai tai, conform rationamentului
de mai sus dar a mai si adaugat 8 dintr-un foc.
Logica nu exista, si tind sa cred ca a daugat 8 pentru cei 4 care
reprezinta adresa de intoarcere inapoi si EBP-ul care a fost stocat pe
stiva INSA el scade 8 dupa ce s-au scazut deja automat prin call si
push.
Sa fie oare GCC atat de idiot ?
Dumitru Stama
z> Cand gcc-ul compileaza o functie, primul lucru pe care il face functia e
z> sa scada o anumita valoare din registrul ESP, pentru a face loc
z> variabilelor locale. Aceasta valoare care este scazuta este intotdeauna
z> >= decat dimensiunea variabilor, dar as fi curios sa aflu dupa ce
z> algoritm decide gcc-ul cu cat sa fie mai mare.
z> Exemplu: Am urmatoarea secventa de cod in C:
z> ---start------------------
z> void f1() {
z> char d[3];
z> }
z> void f2() {
z> char d[4];
z> }
z> ---end--------------------
z> As dori sa aflu de ce se scade 24 cand variabila locala are 3 octeti si
z> 4 cand variabila are 4 octeti.
z> ---
z> Detalii despre listele noastre de mail: http://www.lug.ro/
--
Best regards,
Dumitru mailto:[EMAIL PROTECTED]
---
Detalii despre listele noastre de mail: http://www.lug.ro/
