İlk derleyici neden ilk tercümandan önce yazıldı?

İlk derleyici 1952'de Grace Hopper tarafından, Lisp tercümanı 1958'de John McCarthy'nin öğrencisi Steve Russell tarafından yazılmıştır. Derleyici yazmak, tercümandan çok daha zor bir problem gibi görünüyor. Öyleyse, neden ilk derleyici ilk tercümandan altı yıl önce yazılmış?

Derleyici yazmak, tercümandan çok daha zor bir problem gibi görünüyor.

Bugün doğru olabilir, ancak 60 yıl önce durum böyle olmadığını savunuyorum. Bunun birkaç nedeni:

• Bir tercüman ile hem programı hem de hafızada tutmanız gerekir. 1kb hafızanın büyük bir lüks olduğu bir çağda, çalışan hafızanın ayak izini düşük tutmak kilit öneme sahipti. Ve yorumlama, derlenmiş bir programı çalıştırmaktan biraz daha fazla bellek gerektirir.
• Modern CPU'lar büyük talimat kataloglarıyla oldukça karmaşıktır. Bu yüzden iyi bir derleyici yazmak gerçekten zor bir iştir. Eski CPU'lar daha basitti, derleme bile daha basitti.
• Modern diller eski dillerden çok daha karmaşıktır, bu nedenle derleyiciler bile daha karmaşıktır. Eski diller böylece daha basit derleyiciler olurdu.

Temel nokta, 1950'lerin bilgi işlem donanım ortamının, o zamanlar bilgisayarların toplu yönelimli işlenmesi göz önüne alındığında, yalnızca bir derleyicinin mümkün olmasını sağlamasıydı.

O zamanlar, daha iyi kullanıcı arayüzleri esasen delikli kartlar ve teletype yazıcılar ile sınırlıydı . 1961'de SAGE sistemi bilgisayardaki ilk Katot-Işın Tüpü (CRT) ekranı oldu. Bu nedenle, bir tercümanın etkileşimli doğası, daha sonraya kadar tercih edilemez ya da doğal değildi.

1950'lerde sayısız bilgisayar, talimatları yüklemek için ön panel anahtarlarını kullandı ve çıktı basitçe lamba / LED sıralarıydı ve hobiler bile 1970'lerde ön panel anahtarlarını ve LED'lerini kullandılar. Belki de ünlü Altair 8800'ü tanıyorsunuzdur .

Diğer donanım sınırlamaları da tercümanları olanaksız kılıyor. 1950'lerde bilgisayarlarda birincil bellek (örn. RAM) aşırı sınırlı kullanılabilirliği vardı. Yarı iletken tümleşik devreden önce (ki bu 1958'e kadar gelmedi) bellek, manyetik çekirdekli bellek ya da bit ya da sözcüklerle ölçülen gecikme hattı belleği ile sınırlıydı , ön ek. İkincil depolama belleğinin yavaşlığı (örneğin, disk veya teyp) ile birlikte, yorumlayıcı için kullanılan belleğin büyük bir kısmına sahip olmanın mümkün olmadığı durumlarda, yorumlayıcı program yüklenmeden önce bile zararlı olduğu kabul edilir.

IBM’deki John Backus’un liderliğini yaptığı FORTRAN derleyicisini 1954-57’de oluşturduğunda, bellek kısıtlamaları hala önemli bir faktördü. Bu yenilikçi derleyici, yalnızca optimize edici bir derleyici olduğundan başarılı oldu .

1950'lerde bilgisayarların çoğunda, dinamik bağlantı ve sanal bellek yönetimi gibi modern özelliklerin yanı sıra, herhangi bir İşletim Sistemine neredeyse hiç sahip değildi , bu nedenle tercüman fikri o zaman çok radikal ve pratikti.

ek

1950'lerin dilleri ilkeldi. Bunlar genellikle altta yatan donanımın talimatlarından veya hedeflenen kullanımlarının problem tanımından etkilenen küçük bir avuç dolusu işlem içeriyordu .

O zamanlar bilgisayarlar bugün nadiren genel amaçlı bilgisayarlardı; Yeniden inşa edilmek zorunda kalmadan yeniden programlanabilir olduklarının devrimci bir kavram olduğu düşünülüyordu - daha önce insanlar cevapları hesaplamak ya da hesaplamak için elektromekanik makineler kullanıyorlardı (tipik olarak hesap makineleri) ( 1950'lerde uygulamaların çoğu doğada sayısaldı).

Bir Bilgisayar Bilimi bakış açısına göre, derleyiciler ve tercümanlar hem çevirmendir , hem de kabaca uygulanması karmaşıktır.

İlk programlama dilleri oldukça basitti (örneğin, özyinelemesiz) ve kendisi de basit olan makine mimarisine yakındı. Çeviri sonra basit bir işlemdi .

Bir derleyici, program yürütme verilerini ve kaynak kodu yorumlama tablolarını bir arada tutması gereken bir tercümandan daha basitti. Ve tercüman , kendisi için program kaynak kodu ve sembolik tablolar için daha fazla yer kaplardı.

Hafıza o kadar az olabilir ki (hem maliyet hem de mimari sebeplerden dolayı), derleyiciler işletim sisteminin üzerine yazılan bağımsız programlar olabilir (bunlardan birini kullandım). Derlenmiş programı çalıştırmak için işletim sisteminin derlemeden sonra yeniden yüklenmesi gerekiyordu. ... bu, gerçek iş için tercüman çalıştırmanın bir seçenek olmadığını açıkça ortaya koyuyor .

Doğruyu söylemek gerekirse, derleyicilerin gereken sadeliği derleyicilerin çok iyi olmadığı şekilde olmuştur (kod optimizasyonu henüz düşünüldüğünde, henüz başlangıç ​​aşamasındaydı). Elle yazılmış makine kodu, en azından bazı yerlerdeki altmışlı yılların sonlarına kadar, derleyici tarafından üretilen koddan önemli ölçüde daha verimli olma ününe sahipti. Derlenmiş kodun boyutunu çok iyi bir programcının çalışmasıyla karşılaştıran bir kod genişletme oranı kavramı bile vardı . Çoğu (tümü?) Derleyiciler için genellikle 1'den büyüktü; bu, daha yavaş programlar ve daha da önemlisi daha fazla bellek gerektiren daha büyük programlar anlamına geliyordu. Bu hala altmışlı yıllarda bir sorun oldu.

Derleyicinin ilgisi, özellikle çeşitli alanlardaki bilim adamları gibi bilgi işlem uzmanı olmayan kullanıcılar için programlama kolaylığıydı. Bu ilgi kod performansı değildi. Ancak yine de programcının zamanı daha ucuz bir kaynak olarak kabul edildi. Maliyet bilgisayardan, 1975-1980'e kadar, donanımdan yazılıma geçtiğinde idi. Bu, derleyicinin bile bazı profesyoneller tarafından ciddiye alınmadığı anlamına gelir .

Bilgisayar süresinin çok yüksek maliyeti, tercümanların diskalifiye edilmesinin bir başka nedenidir , yani fikrin çoğu insan için gülünç olacağı noktaya gelmişti.

Lisp vakası çok özel bir konu, çünkü uygulanabilir hale getiren son derece basit bir dildi (ve bilgisayar 58'de biraz daha büyümüştü). Daha da önemlisi, Lisp tercümanı, herhangi bir kullanılabilirlik sorunundan bağımsız olarak, Lisp'in ( meta-dairesellilik ) öz tanımına ilişkin bir kavram kanıtıydı .

Lisp başarısı büyük ölçüde, bu kendiliğinden tanımlanabilirliğin onu programlama yapılarını incelemek ve yeni diller tasarlamak için (ve ayrıca sembolik hesaplamaya uygun olması için) mükemmel bir test ortamı haline getirmesinden kaynaklanmaktadır.

Sorunun öncülüne katılmıyorum.

Amiral Hopper'ın ilk derleyicisi (A-0) daha çok bağlayıcı ya da makro dili gibiydi. Bir kasette alt rutinleri sakladı (her biri bir numara atandı) ve programları alt rutinlerin ve argümanların bir listesi olarak yazılacaktı. Derleyici, istenen alt yordamları banttan kopyalar ve bunları tam bir programa yeniden sıralar.

"Derleme" kelimesini, şiirlerin bir antolojisini derlediği gibi kullandı: çeşitli eşyaları bir ciltte bir araya getirmek.

Bu ilk derleyicide, söyleyebileceğim kadarıyla, onu modern bir derleyicinin uzak atası yapan bir söz sahibi ya da çözümleyici yoktu. Daha sonra daha ingilizce benzeri bir sözdizimi amacıyla başka bir derleyici (B-0, aka FLOW-MATIC) yarattı, ancak 1958 ya da 1959 yılına kadar tamamlanmadı - Lisp tercümanı ile aynı zamanda.

Bu nedenle, sorunun kendisinin biraz hatalı olduğunu düşünüyorum. Derleyicilerin ve tercümanların aynı anda neredeyse tam olarak aynı anda geliştiği görülüyor, pek çok bilim insanının aynı gün boyunca aynı çizgide düşünmesini sağlayacak fikirlerin paylaşımı nedeniyle hiç şüphesiz.

Buradaki alıntılarla daha iyi bir cevap: https://stackoverflow.com/a/7719098/122763 .

Denklemin diğer kısmı, derleyicilerin bir birleştiricinin üzerinde bir adım soyutlaması olmasıdır. İlk önce kodlanmış makine kodumuz vardı. "Biz" montajcıydık. Her atlama ve ofset, vb., Hex (veya sekizli) olarak elle hesaplandı ve daha sonra kağıt bant veya kartlara delindi. Yani montajcılar sahneye çıktığında, çok büyük bir zaman kazandı. Bir sonraki adım makro montajcılarıydı. Bu, bir dizi makine talimatına yayılacak bir makro yazma yeteneği verdi. Yani Fortran ve Cobol ileriye doğru büyük bir adım attılar. Kaynakların eksikliği (depolama, bellek ve işlemci döngüleri), genel amaçlı tercümanların teknolojinin büyümesini beklemesi gerektiği anlamına geliyordu. İlk tercümanların çoğu bayt kodlu motorlardı (bugün Java veya CLR gibi, ancak daha az yetenekli). UCSD Pascal çok popüler (ve hızlı) bir dildi. MS Basic, başlık altında bir byte kod motoruydu.

Genel giderler açısından, hangi işlemcinin çalıştırıldığına tamamen bağlıydı. Endüstri bir süredir CISC kargaşasına karşı büyük bir RISC'den geçti. Şahsen IBM, Data General, Motorola, Intel (göründüğünde), TI ve diğer birçokları için assembler yazdım. Bir p kodunu "yorumlamak" için gerekenleri etkileyecek olan talimat kümelerinde, kayıt defterlerinde vs. oldukça önemli bir fark vardı.

Bir zaman referansı olarak, 1972'de telefon şirketinden programlama yapmaya başladım.

Her şeyi bellekte tutmuyorsanız, derlenmiş kod çok daha hızlıdır. Unutmayın, bu zamanlarda fonksiyonlar derlenen koda dahil edildi. Derleme yapmazsanız, hangi fonksiyonlara ihtiyacınız olacağını bilmiyorsunuz. Yani, işlevleri çağırıyorsunuz ... Ah, henüz diskten değil, 50 bağların başındayız, fakat kartlardan! Çalışma zamanı!

Elbette, bir geçici çözüm bulmak mümkündür, ancak diller henüz bulunamamıştır, çünkü diller çok basitti ve makine kodundan çok uzak değildi. Ve derleme kolay ve yeterliydi.

İlk derleyici yazılmadan önce insanlar düz ikili kodla karşılaştırıldığında çok büyük bir ilerleme olan assembler kodunu yazdılar. O zaman, bir derleyici tarafından derlenen kodun, montajcı kodundan daha az etkili olacağına dair güçlü bir argüman vardı - o zamanlar (bilgisayar maliyeti) ile (programcı maliyeti) arasındaki ilişki bugünden çok daha farklıydı. Bu yüzden derleyicilere bu açıdan güçlü bir direnç geldi.

Ancak derleyiciler tercümanlardan çok daha etkilidir. O zaman tercüman yazmayı önerseydin, insanlar senin deli olduğunu düşünürlerdi. Bir milyon dolarlık bilgisayar satın alıp daha sonra kodunu yorumlama gücünün% 90'ını boşa harcayabileceğinizi düşünebiliyor musunuz?

Bir döngü programının yorumlanabilmesi için, tekrar tekrar okunabilen bir ortamda saklanması gerekir. Çoğu durumda, tek uygun ortam RAM olacaktır. Kod, tipik olarak - okunabilir diller için - büyük ölçüde boş olması muhtemel olan delikli kartlara girileceği için, RAM'de depolanmadan önce kod üzerinde bir tür işlem yapılması gerekir. Çoğu durumda, delikli kart metnini işlemcinin doğrudan yürütmesi için uygun bir forma sokmak, bir tercüman aracılığıyla verimli bir şekilde işlenebilecek bir forma dönüştürmekten çok daha zor değildir.

İlk derleyicilerin hedefinin diskte bir montaj dili veya nesne kodu dosyası üretmek değil, RAM'de yürütmeye hazır olan kodu sonlandırmak olduğunu unutmayın. Bu, içine girecek bir işletim sistemi olmadığında şaşırtıcı bir şekilde kolaydır. Bir derleyici, belleğin bir ucundan başlayarak kod üretebilir ve diğerinden başlayarak değişkenleri ve dal hedeflerini tahsis edebilir. Bir deyim "1234" etiketiyle işaretlenmişse, derleyici geçerli kod oluşturma adresine atlamak için bir komut "1234" olarak adlandırılan değişkende saklar, yoksa bu değişkeni oluşturur. "Goto 1234" ifadesi, mevcut değilse "1234" değişkeni yaratacak ve daha sonra bu değişkene atlayacaktır (umarım bu ifade çalıştırılmadan önce içinde depolanan uygun yere atlayacaktır).gotoHenüz tanımlanmamış bir etiket, çünkü ne zaman gotoatlayacağı derlenir - bir değişkene. Kod oluşturmanın en etkili yolu bu olmayabilir, ancak bilgisayarların işlemesi beklenen programların boyutları için bu yeterlidir.

Çünkü tercümanların çalışması için derleyicilere ihtiyacı vardır.

Yukarıdaki ifade gerçekten doğru değil. Kesin konuşmak gerekirse, sen yapabilirsiniz şimdiye kullanarak ya da başka bir derleyici ile etkileşime girmeden bir tercüman yapmak. Ancak bunu yapmanın sonuçları, bu terimlerle ne demek istediğinizi düşündüğüm gibi görünmez.

Kesin anlamda, derleyiciler ve tercümanlar tamamen farklı şeyler yaparlar. Bir derleyici, bir kaynaktan gelen metni okur ve başka bir biçime dönüştürür: montaj dili, makine kodu, başka bir üst düzey dil, bir veri yapısı veya başka bir şey. Bu arada bir tercüman da bir tür veri yapısına bürünmekte ve buna dayalı talimatlar uygulamaktadır.

Bugünlerde "derleyici" olarak düşünme eğiliminde olduğumuz şey aslında bir kod oluşturucu ile eşleştirilen bir derleyicidir : bazı kaynaklardan veri alan ve gördüklerini temel alan bir kod çıktısı veren bir program. Bu derleyiciler için oldukça sezgisel bir kullanımdır ve derleyicilerin yaratıldığı ilk şeylerden biriydi. Ancak, başka bir şekilde bakarsanız, bu bir tercümanın yaptığı ile çok benzer görünüyor. Daha genel işlemler yapmak yerine her zaman kod çıkarır, ancak ilke aynıdır.

Buna diğer taraftan bakarsak, bir tercümanın verilerini bir yerden alması gerekir . Bu sadece veridir, yani başka türlü veri oluşturduğunuz şekilde oluşturabilirsiniz. Yorumdan bahsettiğimizden, verilerinizi bir metin dosyasındaki talimatlara dayanarak oluşturmanız doğal görünüyor. Ama bunu yapmak için, metinde okuyacak ve veri yapınızı oluşturacak bir şeye ihtiyacınız olacak ve bu bir derleyici . Kod oluşturucu yerine tercümana bağlı, ama aynı şekilde bir derleyici.

Bu yüzden ilk önce derleyiciler yazılmıştı. Veri yapılarını yorumlama fikri, derleyiciler tasarlandığında bile yeni değildi, ancak derleyiciler programcıların bu yapıları metnin dışına inşa etmelerini sağlayan "eksik bağlantı" idi.

Diğer bir faktör: İlk derleyiciler yazıldığında, makine zamanının maliyeti şimdi olduğundan çok daha fazlaydı. Tercümanlar çok daha fazla makine kullanıyor.