Neden stack kullanılır?

[atix]

Merhaba.
Herhangi bir uygulamada niçin stack kullanımına ihtiyaç duyarız? Bilgileri stack atıp daha sonra ordan okumak daha mı hızlı?
Bizim string x="5"; gibi tanımladığımız değişkenler beleğin neresinde tutulur?Değişkenlerin saklanması için bellkete özel bir yer var mıdır?Yoksa herhangi bir bellek alanımı mı kullanılır?

[naesse]

http://lambda.uta.edu/cse5317/notes/node33.html

http://www.memorymanagement.org/glossary/s.html#stack.allocation

bu adresler soruna cevap olabilir umarım

[acehreli]

Yigitlar yaptigimiz islemler sirasinda ne kadar dibe dallanilacagi ve ne kadar seyin akilda tutulacagi bilinmediginde yararlidir.

Programlarin isleyisi sirasinda da islevler cagrilirken ne kadar derine gidilecegi bilinmedigi icin yigit yararli olmustur. Bir islev cagrilirken icinde bulunulan kapsamdaki bilgi (degiskenler, vs.) yigita atilir, bir anlamda tekrar donene kadar unutulur ve cagrilan islevdeki yeni bilgiyle islem yapilir.

Cagrilan islevden donunce, cagiran islevdeki bilgi yigitta bizi beklemektedir; ise devam... Yani bence yigit "boyle dallanmali bir ise uygun oldugu icin" kullanilmistir. :)

Ali

[Sabahi]

Bir islev cagrilirken icinde bulunulan kapsamdaki bilgi (degiskenler, vs.) yigita atilir, bir anlamda tekrar donene kadar unutulur ve cagrilan islevdeki yeni bilgiyle islem yapilir.

Ali
Yanlis hatirlamiyorsam, C++ compiler yerel degiskenlerin sayisina bagli olarak, veya herhangi bir degiskenin ne oranda kullandildigina bagli olarak degiskeni stack yada register uzerinde saklamaya karar verebilir. Her nekadar "register" keyword kullanarak bir degiskenin register uzerinde saklanmasi icin tiyo verebilsekte derleyeci bunu kaale almayabilir.
Uzun sozun kisasi, yerel degiskenlerin nereye atildigi kullandigimiz derleyiciye ve bu derleyicinin kullandigi optimization algoritmalarina baglidir.

[acehreli]

Kesinlikle haklisin; "yerel degiskenler nerede olusturulur" sorusuna ben de oyle bir yanit verirdim. Hatta, daha once de konustugumuz gibi; standart, yerel nesnelerin yigitta saklanmalarindan da soz etmez. Ama yigitin neden kullanildigi sorusu sorulunca, onun kullanilmasi icin gecerli bir neden oldugunu varsaymisim.

Yine de, is islev cagirmaya gelince; yerel islemler sirasinda yazmacta (register) tutulmasina karar verilmis olan yerel bir nesnenin bir isleve dallanilirken yine de yigita yazilacagini dusunebiliriz. Cunku islemcinin kisitli sayidaki yazmacinin, boyle ust duzey bir islevde tanimlanmis olan yerel bir nesneyi uzun sure yazmacta tutabilmesi cok kucuk bir olasiliktir.

Bir derleme biriminde tanimi gorulemeyen bir islevin cagrilmasi bile derleyicinin o yazmaci bos birakmasi icin yeterli olacaktir.

Ben Euclides'e danismak istiyorum: Derleyici derinlere dallanirken yerel nesneleri yigita yazmaya ne kadar yatkindir? Teori de her sey olabilir ama pratikte nasir davraniyorlar?

Ali

[serimc]

bu durum fonksiyonun ne tur bi calling convention ile cagirilidigi ile alakalidir.Olay derleyicinin yatkinligi veya o andaki duruma gore karar vermesi degildir.3 cesit calling convention bulunur.

__cdecl, __stdcall, __fastcall

burda fonksiyon eger fastcall ile cagirilmis ise registerlar kullanilir digerlerinde parametreler stakta tutulur.Borlandin derleyicileri fastcall kullaniyodu yanlis hatirlamiyosam.Microsoftunkiler ise stdcall.Bu konu hakkinda daha ayrintili bilgiyi ve hangi registerlarin kullanildigini asagidaki linkten okuyabilirsiniz.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_argument_passing_and_naming_conventions.asp

Ha bi de arkadasin sorusu .Net framework Class Librarydeki stack sinifi ile alakali imis.Baska bi forumda cevaplandi.

Kolay gelsin...

[acehreli]

Tesekkurler serimc; ama parametrelerin nasil gecirildiklerinin o andaki duruma bagli olmadigini soylemene katilamiyorum. Islemcilerin bir avuc kadar yazmaci vardir. Nasil olur da onlari kullanarak cok sayida dibe dallanan islev cagirabiliriz. Yazmaclarin sayilari yetmez :)

Verdigin yazida bile __fastcall icin "passed in registers, when possible" ("olabiliyorsa yazmaclarla gecirilir") diyor.

Ayrica, o tUr anahtar sozcukler yalnizca parametre gecirmeyi etkilerler. Yigit ise otomatik nesneler icin de kullaniliyor.

Ali

[serimc]

Doğru haklısın.Senin yatkınlık demenden dolayı ben derleyicinin farklı farklı şeyler yaptığını düşünüyorsun sandım ondan ole yazdım.Eksiği düzelteyim eğer fastcall çağırmada registerlar yeterli olmazsa pascal calling conventionunu kullanır derleyici.Yani parametreleri sırasıyla stack'e atar.

Son paragrafında ne demek istediğini anlamadım.

Kolay gelsin...

[acehreli]

Son paragrafi "yigit veri yapisi yerine program yigitini anlamisiz; bari onun yalnizca parametreler icin kullanildigi anlami cikartilmasin" demek icin yazmisim :)

Ali

[Sabahi]

@serimc
Ilk olarak yerel degiskenlerin nerde saklandigi ile Calling Convention arasinda direk bir iliski kurmaniz pek dogru degil. Calling Conventions bir islevin aldigi parametrelerin nasil saklanacagi islev isimlerinin nasil decorated oldugu gibi konulari ilgilendirir ki yukardaki tartismanin disinda kalan bir alan.
Ikinci olarak verdiginiz link sadece Microsoft C++ compiler icin dogru olabilir. Her ne kadar farkli C++ derleyicileri ayni calling convention lari destekleyebilse bile aralarinda fark olabilir. Ornegin Windows icin Intel C++ derleyicisi MS Visual ile ayni konvensiyonlari desteklemekle birlikte stack kullanimi ve parametre gecisi farklidir.
Ucuncu olarak "pascal calling conventionunu kullanir derleyici" derken hangi derleyiciden bahsediyorsun?
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q100832
Son olarak uc cesit calling convention bulunur demissiniz herhalde thiscall convention u unuttunuz.

[serimc]

@SAbahi
Ilk olarak yerel degisken mi?Valla hizli yazmistim onlari acaba yanlis mi yazdim diye bi daha okudum da hic biyerde yerel degiskenden bahsetmedim ki.Onlarin fonk. parametreleri icin oldugunu zaten solemisim. Bi daha oku istersen.

Ikinci olarak tabii ki dedigin dogru.Her derleyiciye gore degisebilir.Hatta assembly ile kendimiz bile yazabiliriz.Hatta bugun yazdik bi yerde :).

Ucuncu olarak kastedigim derleyici yanlis hatirlamiyosam borlandin derleyicisiydi.

Son olarak bak sen de cdecl ve registeri unutmussun :)
Bunlarin sayisi hakkaten cok cdecl, register, pascal, stdcall, safecall... diye gider bu.

Dedim ya acehreli yatkinlik falan deyince bu isin algoritmik oldugunu yani daha dogrusu sole bi mekanizmasi oldugunu solemek adina yazdim genel olarak calling conventionlari.

[acehreli]

serimc, burada benim ve Sabahi'nin kafasini karistiran aslinda biraz da sensin. :) Cunku ben yukaridaki 03/12/2005, 15:29 tarihli yazida hic parametreden bahsetmezken sen parametre aktarimi ile ilgili olan calling convention'lari anlatinca isler karisti.

Dikkat edersen Sabahi'nin benim yanitimdan bir onceki mesajinda da parametre yok... Herhalde onun icin ikimiz hAlA o konuda konusmaya devam ediyoruz.

Bu durumda sana katiliyoruz: parametre aktarimi sirasinda yazmaclarin ne derece kullanildiklari kullanicinin calling convention secimine baglidir.

Yerel bir nesnenin yazmacta tutulup tutulmamasi ise iyilestirme (optimization) seceneklerine baglidir. Bu ikincisi de derleyici algoritmalari ile yurutulur. Benim Euclides'in yanit verebilecegini umdugum sorum da suydu: derleme aninda tam tanimi gorulemeyen bir islev cagrilirken, cagiran islev icinde yazmacta yasayan bir nesne bile yigita yazilmak zorundadir:


int bar(int);

int foo()
{
int i = 0; // <-- yazmacta yasiyor olsun

// bar'in tanimini goremedigi icin, derleyici
// bir yazmaci bar'dan dOnUlene kadar i'ye
// ayirmayi goze alamaz. Onu yigita yazacaktir.
// Euclides? Dogru mu? :)
return bar(i);
}


Dikkat edersen parametre aktarimindan degil, yerel nesne i'den sozediyoruz. Ama su durumda derleyici herhalde i'nin kendisi icin yigiti kullanmayacaktir:


inline int bar(int i)
{
return i + 42;
}

int foo()
{
int i = 0;
return bar(i);
}


Bu durumda ise, bar'in tam tanimini gordugu icin derleyici hic yigiti kullanmayabilir ve i yazmacta yasayabilir.

Ali