GCC ve LLVM-Clang kullandığınız görülüyor el yazısı özyinelemeli kökenli ayrıştırıcıları ve değil üretilen Bison-Flex tabanlı, aşağıdan yukarıya ayrıştırma makinesi.
Buradaki biri lütfen durumun bu olduğunu onaylayabilir mi? Ve eğer öyleyse, ana akım derleyici çerçeveleri neden el yazısı ayrıştırıcıları kullanıyor?
Güncelleme : bu konuyla ilgili ilginç blog burada
Yanıtlar:
Evet:
GCC bir zamanlar bir yacc (bizon) ayrıştırıcı kullanılır, ancak 3.x serisinde bir noktada elle yazılmış bir özyinelemeli kökenli ayrıştırıcı ile değiştirildi: bkz http://gcc.gnu.org/wiki/New_C_Parser için ilgili yama gönderimlerine bağlantılar.
Clang ayrıca elle yazılmış özyinelemeli bir iniş ayrıştırıcı kullanır: http://clang.llvm.org/features.html'nin sonuna yakın "C, Objective C, C ++ ve Objective C ++ için tek bir birleşik ayrıştırıcı" bölümüne bakın .
foo * bar;bir çarpma ifadesi (sonuç kullanılmadan) veya barişaretçi türüne sahip bir değişkenin bildirimi olarak ayrıştırılabilir foo. Hangisi doğru olan bir olmadığına bağlıdır typedefiçin foolookahead herhangi miktarı ile belirlenebilir şey değildir zamanda en kapsamı içindedir. Ancak bu, yinelemeli iniş ayrıştırıcısının bunun üstesinden gelmek için bazı çirkin ekstra makinelere ihtiyaç duyduğu anlamına gelir.
C'nin ayrıştırılmasının zor olduğunu ve C ++ 'nın esasen imkansız olduğunu söyleyen bir halk teoremi var.
Doğru değil.
Doğru olan, C ve C ++ 'nın LALR (1) ayrıştırıcılarını kullanarak ayrıştırma makinesini kırmadan ve sembol tablosu verilerinde dolaşmadan ayrıştırılmasının oldukça zor olmasıdır. Aslında GCC, YACC ve bunun gibi ek bilgisayar korsanlığı kullanarak onları ayrıştırırdı ve evet, bu çirkindi. Artık GCC, el yazısı ayrıştırıcıları kullanıyor, ancak yine de sembol tablosu korsanlığı ile. Clang çalışanları asla otomatik ayrıştırıcı üreteçleri kullanmayı denemedi; AFAIK Clang ayrıştırıcısı her zaman elle kodlanmış özyinelemeli iniş olmuştur.
Doğru olan, C ve C ++ 'nın daha güçlü otomatik olarak oluşturulmuş ayrıştırıcılarla, örneğin GLR ayrıştırıcılarla ayrıştırılmasının nispeten daha kolay olduğu ve herhangi bir hacklemeye ihtiyacınız olmadığıdır. Elsa C ++ ayrıştırıcı bunun bir örneğidir. Bizim C ++ Ön Uç başka (olarak tüm "derleyici" ön uçları vardır, GLR oldukça harika ayrıştırma teknolojisidir) 'dir.
C ++ ön ucumuz GCC'ler kadar hızlı değil ve kesinlikle Elsa'dan daha yavaş; Onu dikkatlice ayarlamak için çok az enerji harcadık çünkü daha acil sorunlarımız var (yine de milyonlarca satır C ++ kodunda kullanıldı). Elsa muhtemelen daha genel olduğu için GCC'den daha yavaştır. Bugünlerde işlemci hızları göz önüne alındığında, bu farklılıklar pratikte çok önemli olmayabilir.
Ancak bugün yaygın olarak dağıtılan "gerçek derleyiciler", köklerini 10 veya 20 yıl veya daha eski derleyicilere dayandırmaktadır. O zaman verimsizlikler çok daha önemliydi ve hiç kimse GLR ayrıştırıcılarını duymamıştı, bu yüzden insanlar nasıl yapacaklarını bildiklerini yaptılar. Clang kesinlikle daha yenidir, ancak daha sonra halk teoremleri "ikna edebilirliklerini" uzun süre korurlar.
Artık bunu bu şekilde yapmak zorunda değilsin. GLR ve diğer bu tür ayrıştırıcıları, derleyici bakımında bir gelişme ile, ön uç olarak çok makul bir şekilde kullanabilirsiniz.
Ne olduğunu doğrudur, Mahallenin iyi derleyici'nın davranışını eşleşen bir dilbilgisi alma zor olmasıdır. Neredeyse tüm C ++ derleyicileri orijinal standardı (çoğu) uygularken, aynı zamanda çok sayıda karanlık köşe uzantısına da sahiptirler, örneğin MS derleyicilerinde DLL özellikleri, vb. Güçlü bir ayrıştırma motorunuz varsa, zamanınızı elde etmeye çalışarak geçirebilirsiniz. ayrıştırıcı oluşturucunuzun sınırlamalarına uyması için gramerinizi esnetmeye çalışmak yerine, son dilbilgisini gerçeğe uyacak şekilde kullanın.
DÜZENLEME Kasım 2012: Bu cevabı yazdığımızdan beri, C ++ ön ucumuzu ANSI, GNU ve MS varyant lehçeleri dahil olmak üzere tam C ++ 11'i işleyecek şekilde geliştirdik. Çok fazla ekstra şey olsa da, ayrıştırma motorumuzu değiştirmemize gerek yok; sadece gramer kurallarını gözden geçirdik. Anlamsal analizi değiştirmek zorunda kaldık ; C ++ 11 anlamsal olarak çok karmaşıktır ve bu çalışma ayrıştırıcının çalışmasını sağlama çabasını batırır.
DÜZENLEME Şubat 2015: ... artık tam C ++ 14'ü işliyor. ( Basit bir kod bitinin GLR ayrıştırmaları için c ++ kodundan insan tarafından okunabilir AST alın ve C ++ 'ın meşhur "en can sıkıcı ayrıştırması" na bakın).
Nisan 2017 DÜZENLEME: Artık (taslak) C ++ 17'yi işliyor.
foo * bar;belirsizlikle nasıl başa çıkıyorsunuz ?
Clang'ın ayrıştırıcısı, diğer birçok açık kaynaklı ve ticari C ve C ++ ön uçları gibi, elle yazılmış özyinelemeli bir ayrıştırıcıdır.
Clang, çeşitli nedenlerle özyinelemeli bir ayrıştırıcı kullanır:
Genel olarak, bir C ++ derleyicisi için bu çok da önemli değil: C ++ 'nın ayrıştırma kısmı önemsiz değil, ama yine de daha kolay kısımlardan biri, bu yüzden basit tutmak için para ödüyor. Anlamsal analiz - özellikle ad arama, başlatma, aşırı yükleme çözümleme ve şablon somutlaştırma - büyüklük sıralamaları ayrıştırmadan daha karmaşıktır. Kanıt istiyorsanız, kodun dağıtımına bakın ve Clang'ın "Sema" bileşenine (anlamsal analiz için) karşı "Ayrıştırma" bileşenine (ayrıştırma için) bakın.
gcc'nin ayrıştırıcısı elle yazılmıştır. . Ben clang için de aynı şeyden şüpheleniyorum. Bu muhtemelen birkaç nedenden dolayıdır:
Bu muhtemelen bir "burada icat edilmedi" sendromu vakası değil, daha çok "ihtiyacımız olan şey için özel olarak optimize edilmiş hiçbir şey yoktu, bu yüzden kendimizinkini yazdık" şeklinde.
Garip cevaplar var!
C / C ++ gramerler bağlamdan bağımsız değildir. Foo * çubuğu nedeniyle bağlama duyarlıdırlar; belirsizlik. Foo'nun bir tür olup olmadığını anlamak için bir daktilo listesi oluşturmalıyız.
Ira Baxter: GLR konunun amacını anlamıyorum. Neden belirsizlikler içeren bir ayrıştırma ağacı inşa edelim? Ayrıştırma, belirsizlikleri çözmek, sözdizimi ağacını oluşturmak anlamına gelir. Bu belirsizlikleri ikinci bir geçişte çözersiniz, bu yüzden bu daha az çirkin olmaz. Benim için çok daha çirkin ...
Yacc bir LR (1) ayrıştırıcı üreticisidir (veya LALR (1)), ancak içeriğe duyarlı olacak şekilde kolayca değiştirilebilir. Ve içinde çirkin hiçbir şey yok. Yacc / Bison, C dilini ayrıştırmaya yardımcı olmak için oluşturulmuştur, bu nedenle muhtemelen bir C ayrıştırıcısı oluşturmak için en çirkin araç değildir ...
GCC 3.x'e kadar C ayrıştırıcısı, ayrıştırma sırasında oluşturulan typedef tablosu ile yacc / bison tarafından üretilir. "İn parse" typedef tablo oluşturma ile, C dilbilgisi yerel olarak bağlamdan bağımsız ve ayrıca "yerel olarak LR (1)" olur.
Şimdi, Gcc 4.x'te, özyinelemeli bir iniş ayrıştırıcısıdır. Gcc 3.x'teki ile tamamen aynı ayrıştırıcıdır, hala LR (1) ve aynı gramer kurallarına sahiptir. Aradaki fark, yacc ayrıştırıcısının elle yeniden yazılmış olması, shift / küçültme artık çağrı yığınında gizli ve "state454: if (nextsym == '(') goto state398" olmamasıdır. Gcc 3.x yacc's ayrıştırıcı, bu nedenle yama yapmak, hataları işlemek ve daha güzel mesajlar yazdırmak ve ayrıştırma sırasında sonraki derleme adımlarından bazılarını gerçekleştirmek daha kolaydır. Bir gcc noob için çok daha az "okunması kolay" kod fiyatına.
Neden yacc'den özyinelemeli inişe geçtiler? Çünkü yacc'nin C ++ 'yı ayrıştırmaktan kaçınmak ve GCC çok dilli derleyici olmayı hayal ettiğinden, yani derleyebileceği farklı diller arasında maksimum kod paylaşabilir. C ++ ve C ayrıştırıcısının aynı şekilde yazılmasının nedeni budur.
C ++, C'den daha zordur çünkü C gibi "yerel olarak" LR (1) değildir, hatta LR (k) değildir. func<4 > 2>Hangisinin 4> 2 ile somutlaştırılmış bir şablon işlevi olduğuna bakın , yani func<4 > 2>
olarak okunması gerekir func<1>. Bu kesinlikle LR (1) değildir. Şimdi düşünün func<4 > 2 > 1 > 3 > 3 > 8 > 9 > 8 > 7 > 8>. Bu, yinelemeli bir inişin belirsizliği birkaç işlev çağrısı fiyatına kolayca çözebileceği yerdir (parse_template_parameter, belirsiz ayrıştırıcı işlevidir. Parse_template_parameter (17tokens) başarısız olursa, parse_template_parameter (15tokens), parse_template_parameter (13tokens) ... işe yarıyor).
Yacc / bison özyinelemeli alt dilbilgilerini eklemenin neden mümkün olmadığını bilmiyorum, belki bu gcc / GNU ayrıştırıcı geliştirmede bir sonraki adım olacak?
Görünüşe göre GCC ve LLVM-Clang el yazısıyla yazılmış özyinelemeli iniş ayrıştırıcıları kullanıyor ve makine tarafından üretilmiş, Bison-Flex tabanlı, aşağıdan yukarıya ayrıştırmayı değil.
Özellikle Bison, bazı şeyleri belirsiz bir şekilde ayrıştırmadan ve daha sonra ikinci bir geçiş yapmadan dilbilgisini idare edebileceğini sanmıyorum.
Haskell's Happy'nin C sözdizimi ile belirli bir sorunu çözebilen monadik (yani duruma bağlı) ayrıştırıcılara izin verdiğini biliyorum, ancak kullanıcı tarafından sağlanan bir durum monadına izin veren hiçbir C ayrıştırıcı üreteci bilmiyorum.
Teorik olarak, hata kurtarma, el yazısı ayrıştırıcı lehine bir nokta olabilir, ancak GCC / Clang ile olan deneyimim, hata mesajlarının özellikle iyi olmadığı yönünde olmuştur.
Performansa gelince - bazı iddialar asılsız görünüyor. Bir ayrıştırıcı üreteci kullanarak büyük bir durum makinesi oluşturmak, bunun bir şeye yol açması gerekir O(n)ve ayrıştırmanın çoğu araçta darboğaz olduğundan şüpheliyim.