Yanıtlar:
Derleyicilerin uygun makine kodu yerine montaj üretmesinin diğer nedeni:
add eax,2bu dile çevrilebilir . 83 c0 0266 83 c0 02use16
Derleyici genellikle üst düzey kodu doğrudan makine diline dönüştürür, ancak bir arka uç makine kodu ve diğer montaj kodu (GCC gibi) yayacak şekilde modüler bir şekilde oluşturulabilir. Kod oluşturma aşaması, daha sonra makine dili veya montaj kodu gibi kullanılabilir bir biçime dönüştürülmesi gereken, makine kodunun bir iç temsili olan "kod" üretir.
Tarihsel olarak bir dizi kayda değer derleyici makine kodunu doğrudan çıktı. Bununla birlikte, bunu yaparken bazı zorluklar vardır. Genellikle bir derleyicinin düzgün çalıştığını doğrulamaya çalışan biri montaj kodu çıktısını incelemeyi makine kodundan daha kolay bulur. Ayrıca, daha sonra iki geçişli bir birleştirici kullanılarak işlenebilen bir montaj dili dosyası üretmek için tek geçişli bir C veya Pascal derleyicisini kullanmak mümkündür (ve tarihsel olarak yaygındı). Doğrudan kod oluşturmak için, iki geçişli bir C veya Pascal derleyicisi kullanılması veya tek geçişli bir derleyici kullanılması ve ardından geri yamalama ileri atlama adreslerinin bazı yolları kullanılması gerekir [bir çalışma zamanı ortamı başlatılan bir programın boyutunu bir sabit nokta, bir derleyici kodun sonuna bir yama listesi yazabilir ve başlangıç kodunun bu yamaları çalışma zamanında uygulamasını sağlayabilir; böyle bir yaklaşım, yürütülebilir boyutu yama noktası başına yaklaşık dört bayt artıracak, ancak program oluşturma hızını artıracaktır].
Amaç hızlı çalışan bir derleyiciye sahip olmaksa, doğrudan kod üretimi iyi sonuç verebilir. Bununla birlikte, çoğu proje için, montaj dili kodunu oluşturma ve birleştirme maliyeti günümüzde gerçekten önemli bir sorun değildir. Derleyicilerin, diğer derleyiciler tarafından üretilen kodlarla güzel bir şekilde etkileşime girebilecek bir biçimde kod üretmesi, derleme sürelerindeki artışı haklı çıkarmak için genellikle yeterince büyük bir avantajdır.
Aynı komut kümesini kullanan platformlar bile farklı yeniden konumlandırılabilir nesne dosyası biçimlerine sahip olabilir. "A.out" (erken UNIX), OMF, MZ (MS-DOS EXE), NE (16 bit Windows), COFF (UNIX Sistem V), Mach-O (OS X ve iOS) ve ELF (Linux ve diğerleri) ve 32 bit Windows'ta XCOFF (AIX), ECOFF (SGI) ve COFF tabanlı Taşınabilir Yürütülebilir (PE) gibi varyantların varyantları. Derleme dili üreten bir derleyici, nesne dosyası biçimleri hakkında çok fazla bilgi sahibi olmak zorunda değildir, bu da derleyici ve bağlayıcıya bu bilgiyi ayrı bir işlemde kapsülleme olanağı sağlar.
Ayrıca bkz . Yığın Taşması sırasında OMF ve COFF arasındaki fark .
Genellikle derleyiciler talimat dizileri ile dahili olarak çalışır. Her komut, işlem adını, işlenenleri ve benzerlerini temsil eden bir veri yapısı ile temsil edilecektir. İşlenenler adres olduğunda, bu adresler genellikle somut değerler değil, sembolik referanslar olacaktır.
Çıktı toplayıcı nispeten basittir. Derleyicilerin dahili veri yapısını alıp belirli bir formatta bir metin dosyasına dökmek meselesi. Birleştirici çıktısının okunması da nispeten kolaydır, bu da derleyicinin ne yaptığını kontrol etmeniz gerektiğinde yararlıdır.
İkili nesne dosyalarının çıktısı önemli ölçüde daha fazla iştir. Derleyici yazarının tüm talimatların nasıl kodlandığını (bazı CPUS'ta önemsiz olmaktan uzak olabileceğini) bilmesi gerekir, bazı sembolik referansları program sayacı göreli adreslerine ve diğerlerini ikili nesne dosyasındaki bir meta veri biçimine dönüştürmeleri gerekir. . Her şeyi son derece sisteme özgü bir formatta yazmaları gerekiyor.
Evet, derleyici bir ara adım olarak yazmadan doğrudan ikili nesneleri çıktı alabilen bir derleyici yapabilirsiniz. Yazılım geliştirmede pek çok şey gibi soru, derleme süresindeki azalmanın ekstra geliştirme ve bakım çalışmalarına değip değmeyeceğidir.
En çok tanıdığım derleyici (freepascal) tüm platformlarda derleyici çıktısı alabilir, ancak yalnızca ikili nesneleri doğrudan bir platform alt kümesinde çıktılayabilir.
Bir derleyici, programlayıcının yararına normal yeniden yerleştirilebilir koda ek olarak bir montajcı çıkışı üretebilmelidir.
Bir keresinde bir LSI-11 makinesinde Unix System V üzerinde çalışan bir C programındaki hatayı bulamıyorum. Hiçbir şey işe yaramadı. Sonunda çaresizlik içinde, protable C derleyicisinin çevirisinin bir montajcı versiyonunu atlattım. Sonunda böcek buldum! Derleyici makinede olduğundan daha fazla kayıt tahsis ediyordu! (Derleyici, R0 - R8 kayıtlarını yalnızca R0 - R7 kayıtlarına sahip bir makineye ayırır.) Derleyicideki hata etrafında çalışmayı başardım ve programım çalıştı.
Montajcı çıktısına sahip olmanın diğer bir yararı, farklı bir parametre geçirme protokolü kullanan "standart" kitaplıkları kullanmaya çalışmaktır. Daha sonra C derleyicileri protokolü bir parametreyle ayarlamama izin verir ("pascal" derleyicinin parametreleri ters sırada C standardının tersine verilen sırayla eklemesini sağlar).
Yine başka bir fayda, programcının derleyicisinin ne kadar korkunç bir iş yaptığını görmesine izin vermektir. Basit bir C ifadesi yaklaşık 44 makine talimatı alır. Değerler bellekten yüklenir ve daha sonra hızla atılır. vs, vs, vs ...
Şahsen, yeniden yerleştirilebilir bir nesne modülü yerine bir derleyiciye sahip olmanın gerçekten aptal olduğuna inanıyorum. Programınızı derlerken, derleyici programınız hakkında çok fazla bilgi toplar. Genellikle tüm bu bilgileri Sembol Tablosu adı verilen bir yerde saklar. Montajcı kodu atıldıktan sonra tüm bu bilgi tablosunu atar. Montajcı daha sonra atılan kodu inceler ve derleyicinin zaten sahip olduğu bazı bilgileri yeniden toplar. Ancak, çevirici If ifadeleri veya While ifadeleri hakkında hiçbir şey bilmiyor. Yani tüm bu bilgiler eksik. Daha sonra montajcı, derleyicinin yeniden yerleştirilemediği nesne modülünü üretir.
Neden???