Programları yapılandırmanın tek makul yolu yığınlar mı?

Gördüğüm mimarların çoğu, işlev çağrıları öncesi bağlamı kaydetmek / geri yüklemek için bir çağrı yığına güveniyor. Push ve pop işlemlerinin çoğu işlemciye yerleşik olması çok yaygın bir paradigmadır. Yığın olmadan çalışan sistemler var mı? Eğer öyleyse, nasıl çalışırlar ve ne için kullanılırlar?

Bir çağrı yığına popüler bir alternatif (biraz), sürekliliktir .

Parrot VM, örneğin devam temellidir. Tamamen yığınsızdır: veriler kayıtlarda tutulur (Dalvik veya LuaVM gibi, Papağan kayıt tabanlıdır) ve kontrol akışı sürekliliklerle temsil edilir (Dalvik veya bir çağrı yığını olan LuaVM'in aksine).

Tipik olarak Smalltalk ve Lisp VM'ler tarafından kullanılan bir başka popüler veri yapısı da, bir yığın yığın ağına benzeyen spagetti yığınıdır.

@ Rwong'un belirttiği gibi , devam eden stil bir çağrı yığınına bir alternatiftir. Devamlı geçiş tarzında yazılmış (veya dönüştürülmüş) programlar asla geri dönmez, bu nedenle yığına gerek kalmaz.

Sorunuzu farklı bir perspektiften cevaplama: Yığın karelerini öbek üzerine atayarak, ayrı bir yığına sahip olmadan bir çağrı yığınının olması mümkündür. Bazı Lisp ve Scheme uygulamaları bunu yapar.

Eski günlerde, işlemcilerde yığın yönergeleri yoktu ve programlama dilleri özyinelemeyi desteklemedi. Zaman geçtikçe, daha fazla dil özyinelemeyi desteklemeyi ve donanımın ardından yığın çerçeve tahsisi özelliklerine sahip bir paketi seçti. Bu destek farklı işlemcilerle yıllar içinde büyük ölçüde değişmiştir. Bazı işlemciler yığın çerçevesini ve / veya yığın işaretçi kayıtlarını kabul etti; Bazıları, yığın çerçevelerin tek bir komutta tahsis edilmesini sağlayacak talimatları kabul etti.

İşlemciler tek seviyeli, sonra çok seviyeli önbelleklerle ilerlerken, yığının önemli bir avantajı önbellek konumudur. Yığının üstü neredeyse her zaman önbellekte. Ne zaman büyük bir önbellek isabet oranına sahip bir şey yapabilirseniz, modern işlemcilerle doğru yoldasınız. Yığına uygulanan önbellek, yerel değişkenlerin, parametrelerin, vb. Hemen hemen her zaman önbellekte olduğu ve en yüksek performans düzeyinin keyfini çıkardığı anlamına gelir.

Kısacası, yığının kullanımı hem donanımda hem de yazılımda gelişti. Başka modeller de var (örneğin, veri akışı hesaplama uzun bir süredir deneniyordu), ancak yığının konumu gerçekten iyi çalışmasını sağlıyor. Dahası, prosedürel kod, işlemciler için tam da istediği şeydir: performans için: bir talimat diğerine ne yapılması gerektiğini söyleyen bir talimat. Talimatlar doğrusal sıralamanın dışında kaldığında, işlemci sırayla erişim kadar hızlı nasıl rasgele erişim yapabileceğimizi çözemediğimizden, en azından henüz, çok yavaşlar. (BT, her bellek düzeyinde, önbellekten ana belleğe, diske kadar ... benzer sorunlar vardır.)

Sıralı erişim talimatlarının gösterilen performansı ve çağrı yığınının yararlı önbellek davranışı arasında, en azından şu anda kazanan bir performans modeline sahibiz.

(Veri yapılarının değişkenliğini eserlere de dahil edebiliriz ...)

Bu, diğer programlama modellerinin çalışamayacağı anlamına gelmez, özellikle sıralı talimatlara çevrilebildiklerinde ve bugünün donanımının yığın modelini arayabildiklerinde. Ancak, donanımın nerede olduğunu destekleyen modeller için belirgin bir avantaj var. Ancak, işler her zaman aynı kalmaz; bu nedenle, gelecekteki değişiklikleri farklı bellek ve transistör teknolojilerinin daha fazla paralelliğe izin verdiği gibi görebiliriz. Programlama dilleri ve donanım yetenekleri arasında her zaman şaka yapar, bu yüzden göreceğiz!

TL; DR

• Bir fonksiyon çağırma mekanizması olarak çağrı yığını:
  1. Tipik olarak donanım tarafından simüle edilir, ancak donanım yapımında temel değildir
  2. Zorunlu programlama için temeldir
  3. İşlevsel programlama için temel değil
• "Son giren ilk çıkar" (LIFO) soyutlaması olarak yığın, bilgisayar bilimleri, algoritmalar ve hatta bazı teknik olmayan alanlar için temeldir.
• Çağrı yığınlarını kullanmayan bazı program organizasyonu örnekleri:
  • Devam eden stil (CPS)
  • Durum makinesi - her şey belirtildiği gibi dev bir döngü. (Saab Gripen donanım yazılımı mimarisinden ilham alması ve Henry Spencer tarafından bir iletişime atfedilmesi ve John Carmack tarafından çoğaltılması iddia edilmiştir.) ^{(Not # 1)}
  • Veri akışı mimarisi - sıralarla birbirine bağlanmış bir aktörler ağı (FIFO). Kuyruklara bazen kanal denir.

Bu cevabın geri kalanı, düşüncelerin ve anekdotların rastgele bir koleksiyonudur ve bu nedenle biraz dağınıktır.

Tanımladığınız yığın (işlev çağrısı mekanizması olarak) zorunlu programlamaya özgüdür.

Zorunlu programlama altında, makine kodunu bulacaksınız. Makine kodu, küçük bir talimat dizisi uygulayarak çağrı yığınını taklit edebilir.

Makine kodunun altında, yazılımı çalıştırmaktan sorumlu donanımı bulacaksınız. Modern mikroişlemci burada tarif edilemeyecek kadar karmaşık olsa da, yavaş ve aynı makine kodunu uygulayabilecek kadar basit bir tasarımın var olduğu düşünülebilir. Böyle basit bir tasarım dijital mantığın temel unsurlarından faydalanacaktır:

1. Kombinasyonel mantık, yani mantık kapılarının bağlantısı (ve, veya, değil ...) "Birleşimsel mantığın" geri bildirimleri dışladığına dikkat edin.
2. Bellek, yani parmak arası terlikler, mandallar, yazmaçlar, SRAM, DRAM, vb.
3. Donanımın geri kalanını yöneten bir "denetleyici" uygulayabilmesi için bir miktar birleşik mantık ve biraz bellekten oluşan bir durum makinesi.

Aşağıdaki tartışmalar, zorunlu programları yapılandırmada birçok alternatif yöntem örneği içeriyordu.

• http://number-none.com/blow/john_carmack_on_inlined_code.html
• https://news.ycombinator.com/item?id=8374345

Programın yapısı şöyle görünecektir:

void main(void)
{
    do
    {
        // validate inputs for task 1
        // execute task 1, inlined, 
        // must complete in a deterministically short amount of time
        // and limited to a statically allocated amount of memory
        // ...
        // validate inputs for task 2
        // execute task 2, inlined
        // ...
        // validate inputs for task N
        // execute task N, inlined
    }
    while (true);
    // if this line is reached, tell the programmers to prepare
    // themselves to appear before an accident investigation board.
    return 0; 
}

Bu stil, mikrodenetleyiciler için, yani yazılımı, donanımın işlevlerine eşlik eden kişiler için uygun olacaktır.

Hayır, mutlaka değil.

Appel'in eski makalesi olan Çöp Toplama Yığın Tahsisinden daha hızlı olabilir . Devamlı geçiş stilini kullanır ve yığınsız bir uygulama gösterir.

Ayrıca eski bilgisayar mimarilerinin (örn. IBM / 360 ) herhangi bir donanım yığını kaydına sahip olmadığına dikkat edin. Ama işletim sistemi ve derleyici yığın işaretçi için bir kayıt ayrılmış Kongre (ilgili kuralları çağıran bir yazılım var, öyle ki) çağrı yığını .

Prensip olarak, bütün bir program C derleyicisi ve optimize edici, çağrı grafiğinin statik olarak bilindiği ve herhangi bir özyineleme (veya fonksiyon işaretçisi olmadan) olduğu durumu (gömülü sistemler için biraz yaygın) tespit edebilir. Böyle bir sistemde, her bir işlev, dönüş adresini sabit bir statik konumda tutabilir (ve Fortran77'nin 1970 çağındaki bilgisayarlarda bu şekilde çalışmasıydı).

Bu günlerde, işlemciler aynı zamanda CPU önbelleklerinden haberdar olan çağrı yığınlarına (ve çağrı ve iade makinesi talimatlarını) sahiptir .

Şimdiye kadar iyi cevapların var; Size, yığınlar veya “kontrol akışı” nosyonu olmadan bir dili nasıl tasarlayabileceğinize dair pratik olmayan ancak eğitici bir örnek vereyim. İşte faktörleri belirleyen bir program:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = f(3)

Bu programı bir dizgeye koyduk ve programı metin değişikliği ile değerlendiriyoruz. Bu yüzden, değerlendirirken f(3), bir arama yaparız ve i için 3 ile değiştiririz:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = if 3 == 0 then 1 else 3 * f(3 - 1)

Harika. Şimdi bir başka metin değiştirme işlemi gerçekleştiriyoruz: "if" nin koşulunun yanlış olduğunu ve programı üreten başka bir dize yaptığını görüyoruz:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = 3 * f(3 - 1)

Şimdi, sabitleri içeren tüm alt ifadelerde başka bir dize değiştirelim:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = 3 * f(2)

Ve bunun nasıl gittiğini görüyorsunuz; Daha fazla emek vermeyeceğim. Aşağı inene let x = 6ve bitinceye kadar bir dizi ip yerine geçmeye devam edebiliriz .

Yığını geleneksel olarak yerel değişkenler ve devam bilgisi için kullanırız; unutmayın, bir yığın size nereden geldiğinizi söylemez, o da elinizde bu dönüş değerinin yanında nereye gideceğinizi gösterir.

Dizge programlama modelinde, yığında "yerel değişkenler" yoktur; biçimsel parametreler, işlev yığındaki bir arama tablosuna yerleştirilmek yerine, bağımsız değişkenine uygulandığında değerleri ile değiştirilir. Ve “sonraki bir yere gitme” yoktur, çünkü program değerlendirme, farklı ancak eşdeğer bir program üretmek için string yerine basit kurallar uygulamaktadır.

Şimdi, elbette, aslında sicim yerine geçmek muhtemelen gitmenin yolu değil. Ancak “eşitlikçi akıl yürütmeyi” (Haskell gibi) destekleyen programlama dilleri mantıklı bir şekilde bu tekniği kullanıyor.

1972'de Parnas tarafından sistemlerin modüllere ayrıştırılmasında kullanılacak kriterler üzerine yayınlanması , yazılımda saklanan bilgilerin iyi bir şey olduğu kabul edildi. Bu, 60'lı yıllarda yapısal ayrışma ve modüler programlama konusundaki uzun tartışmaları takip ediyor.

Modülarite

Herhangi bir çok parçacıklı sistemde farklı gruplar tarafından uygulanan modüller arasındaki kara kutu ilişkilerinin gerekli bir sonucu, tekrar girmeye izin verecek bir mekanizma ve sistemin dinamik çağrı grafiğini izlemenin bir yolunu gerektirir. Kontrollü yürütme akışı, birden fazla modülün içine ve dışına geçmelidir.

Dinamik kapsam belirleme

Dinamik davranışı izlemek için sözcüksel kapsam belirleme yetersiz kaldığında, farkı izlemek için bazı çalışma zamanı defter tutma işlemi gerekir.

Herhangi bir iş parçacığı (tanımı gereği) yalnızca tek bir geçerli komut göstergesine sahip olduğu için, her başlatmayı izlemek için bir LIFO yığını uygundur.

İstisnalar

Bu yüzden, devam modeli yığın için açıkça bir veri yapısını korumazken, bir yerlerde tutulması gereken hala iç içe geçmiş modüller çağrısı var!

Beyannameli diller bile değerlendirme geçmişini korur ya da performans nedenleriyle yürütme planını tersine çevirir ve ilerlemeyi bir şekilde sürdürür.

Rwong tarafından tanımlanan sonsuz döngü yapısı , birçok genel programlama yapısına izin vermeyen statik zamanlamaya sahip yüksek güvenilirlikli uygulamalarda yaygındır, ancak tüm uygulamanın, önemli bir bilgi gizlemesi olmayan beyaz bir kutu olarak görülmesini gerektirir.

Birden fazla eşzamanlı sonsuz döngü, işlev çağırmadığı için geri dönüş adreslerini tutmak için herhangi bir yapı gerektirmez, bu da soruyu tartışılır hale getirir. Paylaşılan değişkenleri kullanarak iletişim kurarlarsa, bunlar kolayca eski Fortran tarzı dönüş adresi analoglarına dönüşebilir.

Eski anabilgisayarların (IBM System / 360) hiç bir yığın fikri yok. 260'ta, örneğin, parametreler bellekte sabit bir yerde inşa edildi ve bir alt rutin çağrıldığında, R1parametre bloğuna işaret edilerek ve R14dönüş adresini içeren çağrıldı . Çağrılan rutin, başka bir alt rutini çağırmak istiyorsa, R14bu çağrıyı yapmadan önce bilinen bir konumda saklanması gerekir .

Bu, bir yığından çok daha güvenilirdir, çünkü her şey derleme zamanında oluşturulan sabit bellek konumlarında saklanabilir ve işlemlerin hiçbir zaman yığında bitmemesi% 100 garanti edilebilir. Bugünlerde yapmak zorunda olduğumuz "1MB tahsis et ve parmaklarınızı çarpı" diye bir şey yok.

Tekrarlayan alt rutin çağrılara, anahtar kelime belirtilerek PL / I de izin verildi RECURSIVE. Alt yordam tarafından kullanılan belleğin, statik olarak tahsis edilmek yerine, dinamik olarak kullanılması anlamına geliyordu. Ancak özyinelemeli çağrılar şimdi olduğu kadar nadirdi.

Yığınsız çalıştırma aynı zamanda çok parçacıklı işlemi çok daha kolay hale getirir, bu nedenle modern dilleri sık sık yapma girişimleri yapılır. Hiç bir neden yoktur, örneğin, bir C ++ derleyicisinin yığınlardan ziyade dinamik olarak ayrılmış belleği kullanmak için değiştirilemedi.