संकलक वास्तुकला का एक संक्षिप्त और क्रियात्मक अवलोकन

अधिकांश संकलक में निम्नलिखित वास्तुकला है:



इस लेख में, मैं इस वास्तुकला को विस्तार से बता रहा हूं, तत्व द्वारा तत्व।
हम कह सकते हैं कि यह लेख संकलकों के विषय पर मौजूदा संसाधनों की भारी मात्रा का एक अतिरिक्त है। यह एक स्वायत्त स्रोत है जो आपको प्रोग्रामिंग भाषाओं के डिजाइन और कार्यान्वयन की मूल बातें समझने की अनुमति देगा।

लेख के लक्षित दर्शक वे लोग हैं जिनके संकलनकर्ताओं के काम का विचार अत्यंत सीमित है (अधिकतम यह है कि वे संकलन में शामिल हैं)। हालांकि, मुझे उम्मीद है कि पाठक डेटा संरचनाओं और एल्गोरिदम को समझेंगे।

यह लेख किसी भी तरह से कोड के लाखों लाइनों के साथ आधुनिक उत्पादन संकलकों के लिए समर्पित नहीं है - नहीं, यह एक छोटा पाठ्यक्रम "डमीज़ के लिए संकलक" है जो समझने में मदद करता है कि एक संकलक क्या है।

परिचय

मैं वर्तमान में रस्ट एंड गो से प्रेरित क्रुग सिस्टम भाषा पर काम कर रहा हूं। लेख में मैं अपने विचारों को स्पष्ट करने के लिए एक उदाहरण के रूप में क्रूग का उल्लेख करूंगा। क्रुग विकास के अधीन है, लेकिन पहले से ही https://github.com/krug-lang पर कैस्पर और क्रग रिपॉजिटरी में उपलब्ध है। संकलक की सामान्य वास्तुकला की तुलना में भाषा काफी विशिष्ट नहीं है, जिसने आंशिक रूप से मुझे एक लेख लिखने के लिए प्रेरित किया - लेकिन बाद में उस पर अधिक।

मैं आपको यह बताने में जल्दबाजी करता हूं कि मैं किसी भी तरह से कंपाइलर का विशेषज्ञ नहीं हूं! मेरे पास डॉक्टरेट नहीं है, और मैंने किसी भी औपचारिक प्रशिक्षण से नहीं गुजरा - मैंने अपने खाली समय में अपने दम पर लेख में वर्णित सभी चीजों का अध्ययन किया। मुझे यह भी कहना होगा कि मैं एक कंपाइलर बनाने के लिए वास्तविक, केवल सही दृष्टिकोण का वर्णन नहीं कर रहा हूं, बल्कि मैं छोटे "टॉय" कंपाइलर बनाने के लिए उपयुक्त बुनियादी तरीकों को प्रस्तुत करता हूं।

दृश्यपटल

आइए ऊपर दिए गए आरेख पर जाएं: सीमांत फ़ील्ड पर बाईं ओर दिए गए तीर सी। जैसी जानी-पहचानी और प्रिय भाषा हैं। फ़्रंटेंड कुछ इस तरह दिखता है: लेक्सिकल विश्लेषण -> पार्सर।

लेक्सिकल विश्लेषण

जब मैंने कंपाइलर और भाषा डिजाइन का अध्ययन करना शुरू किया, तो मुझे बताया गया कि लेक्सिकल विश्लेषण टोकन के समान है। हम इस विवरण का उपयोग करेंगे। विश्लेषक इनपुट डेटा को स्ट्रिंग्स या पात्रों की एक धारा के रूप में लेता है और उनमें पैटर्न को पहचानता है, जिसे वह टोकन में काट देता है।

संकलक के मामले में, यह इनपुट के रूप में एक लिखित कार्यक्रम प्राप्त करता है। यह एक फ़ाइल से एक स्ट्रिंग में पढ़ा जाता है, और विश्लेषक अपने स्रोत कोड को टोकन करता है।

enum TokenType { Identifier, Number, }; struct Token { std::string Lexeme; TokenType type; // ... // It's also handy to store things in here // like the position of the token (start to end row:col) }; 

इस टुकड़े में, एक सी-आकार की भाषा में लिखा गया है, आप संरचना को पूर्वोक्त लेक्सेम के साथ-साथ टोकनटेन भी देख सकते हैं, जो इस टोकन को पहचानने का कार्य करता है।

नोट: लेख उदाहरणों के साथ एक भाषा बनाने के लिए एक निर्देश नहीं है - लेकिन बेहतर समझ के लिए, मैं समय-समय पर कोड स्निपेट्स सम्मिलित करूंगा।

विश्लेषक आमतौर पर सबसे सरल संकलक घटक होते हैं। पूरी तरह से, वास्तव में, बाकी पहेली टुकड़ों की तुलना में काफी सरल है। हालांकि यह आपके काम पर बहुत कुछ निर्भर करता है।

सी कोड के निम्नलिखित टुकड़े लें:

 int main() { printf("Hello world!\n"); return 0; } 

एक फाइल से लाइन में पढ़ने और एक लीनियर स्कैन करने के बाद, आप टोकन को स्लाइस करने में सक्षम हो सकते हैं। हम प्राकृतिक तरीके से टोकन की पहचान करते हैं - यह देखते हुए कि इंट एक "शब्द" है, और रिटर्न स्टेटमेंट में एक "नंबर" है। लेक्सिकल विश्लेषक उसी प्रक्रिया को करता है जैसा हम करते हैं - बाद में हम इस प्रक्रिया की अधिक विस्तार से जाँच करेंगे। उदाहरण के लिए, संख्याओं का विश्लेषण करें:

 0xdeadbeef — HexNumber ( ) 1231234234 — WholeNumber ( ) 3.1412 — FloatingNumber (   ) 55.5555 — FloatingNumber (   ) 0b0001 — BinaryNumber ( ) 

शब्दों को परिभाषित करना मुश्किल हो सकता है। अधिकांश भाषाएं अक्षरों और संख्याओं के अनुक्रम के रूप में एक शब्द को परिभाषित करती हैं, और एक पहचानकर्ता को आमतौर पर एक पत्र या अंडरस्कोर के साथ शुरू करना चाहिए। उदाहरण के लिए:

 123foobar := 3 person-age := 5 fmt.Println(123foobar) 

Go में, इस कोड को सही नहीं माना जाएगा और निम्नलिखित टोकन में पार्स किया जाएगा:

 Number(123), Identifier(foobar), Symbol(:=), Number(3) ... 

अधिकांश पहचानकर्ता इस तरह दिखते हैं:

 foo_bar __uint8_t fooBar123 

विश्लेषकों को अन्य समस्याओं को हल करना होगा, उदाहरण के लिए, रिक्त स्थान, बहु-पंक्ति और एकल-पंक्ति टिप्पणियाँ, पहचानकर्ता, संख्या, संख्या प्रणाली और संख्या स्वरूपण (उदाहरण के लिए, 1_000_000) और एन्कोडिंग (उदाहरण के लिए, ASCII के बजाय UTF8 का समर्थन)।

और अगर आपको लगता है कि आप नियमित अभिव्यक्तियों का सहारा ले सकते हैं - तो बेहतर नहीं। खरोंच से विश्लेषक लिखना बहुत आसान है, लेकिन मैं अपने राजा और भगवान रॉब पाइक के इस लेख को पढ़ने की सलाह देता हूं। Regex हमारे लिए उपयुक्त नहीं है, कई अन्य लेखों में इसका वर्णन किया गया है, इसलिए मैं इस बिंदु को छोड़ दूंगा। इसके अलावा, एक विश्लेषक का लेखन अपने आप को लंबे समय तक क्रियात्मक अभिव्यक्तियों के साथ सजीव करने की तुलना में अधिक दिलचस्प है जो कि regex101.com पर 5:24 बजे अपलोड किया गया है। अपनी पहली भाषा में, मैंने टोकेनाइजेशन के लिए split(str) फंक्शन का इस्तेमाल किया - और मैं ज्यादा दूर नहीं गया।

पदच्छेद

पार्सिंग लेक्सिकल विश्लेषण की तुलना में कुछ अधिक जटिल है। कई पार्सर और पार्सर-जनरेटर हैं - यहां खेल बड़े पैमाने पर शुरू होता है।

कंपाइलरों में पार्सर आमतौर पर टोकन के रूप में इनपुट लेते हैं और एक विशिष्ट पेड़ का निर्माण करते हैं - एक अमूर्त सिंटैक्स ट्री या एक पार्सिंग ट्री। उनके स्वभाव से, वे समान हैं, लेकिन कुछ अंतर हैं।

इन चरणों को कार्यों के रूप में दर्शाया जा सकता है:

 fn lex(string input) []Token {...} fn parse(tokens []Token) AST {...} let input = "int main() { return 0; }"; let tokens = lex(input); let parse_tree = parse(tokens); // .... 

आमतौर पर, कंपाइलर कई छोटे घटकों से निर्मित होते हैं जो इनपुट लेते हैं, इसे बदलते हैं, या उन्हें अलग-अलग आउटपुट में परिवर्तित करते हैं। यह एक कारण है कि संकलक बनाने के लिए कार्यात्मक भाषाएँ अच्छी तरह से अनुकूल हैं। अन्य कारण उत्कृष्ट बेंचमार्किंग और काफी व्यापक मानक पुस्तकालय हैं। मजेदार तथ्य: रस्ट कंपाइलर का पहला कार्यान्वयन Ocaml पर था।

मैं आपको इन घटकों को यथासंभव सरल और स्वायत्त रखने की सलाह देता हूं - मॉड्यूलरिटी प्रक्रिया को बहुत सुविधाजनक बनाएगी। मेरी राय में, सॉफ्टवेयर विकास के कई अन्य पहलुओं के बारे में भी यही कहा जा सकता है।

पेड़

पारस का पेड़

यह क्या है? पार्सिंग ट्री के रूप में भी जाना जाता है, यह मोटा पेड़ स्रोत कार्यक्रम की कल्पना करने का कार्य करता है। वे इनपुट प्रोग्राम के बारे में सभी जानकारी (या अधिकतर) रखते हैं, आमतौर पर आपकी भाषा के व्याकरण में वर्णित के समान। प्रत्येक ट्री नोड अनुगामी या गैर-अनुगामी होगा, उदाहरण के लिए, नंबरकॉन्स्टेंट या स्ट्रिंगकॉन्स्टेंट।

सार सिंटेक्स ट्री

जैसा कि नाम से ही स्पष्ट है, एएसडी एक सार वाक्यविन्यास वृक्ष है। पार्सिंग ट्री में आपके कार्यक्रम के बारे में (अक्सर निरर्थक) जानकारी होती है, और एएसडी के मामले में, इसकी आवश्यकता नहीं होती है। एएसडी को संरचना और व्याकरण के बारे में बेकार जानकारी की आवश्यकता नहीं है, जो कार्यक्रम के शब्दार्थ को प्रभावित नहीं करता है।

मान लीजिए कि आपके पेड़ की अभिव्यक्ति है (जैसे (5 + 5) -3) +2। पार्सिंग ट्री में, आप इसे पूरी तरह से स्टोर करेंगे, साथ ही ब्रैकेट, ऑपरेटर और मान 5, 5, 3, और 2। लेकिन आप बस एएसडी के साथ जुड़ सकते हैं - हमें केवल मूल्यों, ऑपरेटरों और उनके आदेश को जानना होगा।

नीचे दी गई छवि अभिव्यक्ति + a / b / c के लिए पेड़ को दिखाती है।


एएसडी का प्रतिनिधित्व निम्नानुसार किया जा सकता है:

 interface Expression { ... }; struct UnaryExpression { Expression value; char op; }; struct BinaryExpression { Expression lhand, rhand; string op; // string because the op could be more than 1 char. }; interface Node { ... }; // or for something like a variable struct Variable : Node { Token identifier; Expression value; }; 

यह दृश्य काफी सीमित है, लेकिन मुझे आशा है कि आप देख सकते हैं कि आपके नोड्स कैसे संरचित होंगे। पार्सिंग के लिए, आप निम्नलिखित प्रक्रिया का सहारा ले सकते हैं:

 Node parseNode() { Token current = consume(); switch (current.lexeme) { case "var": return parseVariableNode(); // ... } panic("unrecognized input!"); } Node n = parseNode(); if (n != null) { // append to some list of top level nodes? // or append to a block of nodes! } 

मुझे आशा है कि आपको उच्च-स्तरीय भाषा निर्माण के साथ शुरू होने वाले शेष नोड्स के चरण-दर-चरण पार्सिंग कैसे आगे बढ़ेगा, इसका संकेत मिलता है। एक पुनरावर्ती वंश के साथ पार्सर वास्तव में कैसे लागू किया जाता है, आपको खुद का अध्ययन करने की आवश्यकता है।

व्याकरण

टोकन के एक सेट से एडीएस में पार्स करना मुश्किल हो सकता है। आमतौर पर आपको अपनी भाषा के व्याकरण से शुरू करना चाहिए। संक्षेप में, व्याकरण आपकी भाषा की संरचना को निर्धारित करता है। भाषाओं को परिभाषित करने के लिए कई भाषाएँ हैं जो स्वयं का वर्णन (या पार्स) कर सकती हैं।

भाषाओं के निर्धारण के लिए एक भाषा का एक उदाहरण बैकस-नौर (आरबीएनएफ) का एक विस्तारित रूप है । यह कम कोण कोष्ठक के साथ BNF की भिन्नता है। यहाँ एक विकिपीडिया लेख से RBNF का उदाहरण दिया गया है:

 digit excluding zero = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ; digit = "0" | digit excluding zero ; 

उत्पादन नियमों को परिभाषित किया गया है: वे संकेत देते हैं कि कौन सा टर्मिनल टेम्पलेट "गैर-टर्मिनल" है। टर्मिनल वर्णमाला का हिस्सा हैं, उदाहरण के लिए, यदि ऊपर दिए गए उदाहरण में टोकन या 0 और 1 हैं। गैर-टर्मिनल उनके विपरीत हैं, वे उत्पादन नियमों के बाईं ओर हैं, और उन्हें टर्मिनलों और गैर-टर्मिनलों के समूहों के रूप में चर या "नामित संकेत" माना जा सकता है।

कई भाषाओं में विनिर्देश होते हैं जिनमें व्याकरण होता है। उदाहरण के लिए, गो , रस्ट और डी।

पुनरावर्ती वंश विश्लेषक

पुनरावर्ती वंश कई पार्सिंग दृष्टिकोणों में सबसे आसान है।

पुनरावर्ती वंश विश्लेषक - पुनरावर्ती प्रक्रियाओं पर आधारित, अवरोही। एक पार्सर लिखना बहुत आसान है, क्योंकि आपके व्याकरण में पुनरावृत्ति नहीं होती है। अधिकांश "खिलौना" भाषाओं में, यह तकनीक पार्सिंग के लिए पर्याप्त है। जीसीसी एक हाथ से लिखे अवरोही पार्सर का उपयोग करता है, हालांकि YACC का उपयोग पहले किया गया था।

हालाँकि, इन भाषाओं को पार्स करने से समस्याएँ हो सकती हैं। विशेष रूप से, सी, जहां

 foo * bar 

के रूप में व्याख्या की जा सकती है

 int foo = 3; int bar = 4; foo * bar; // unused expression 

या कैसे

 typedef struct { int b; } foo; foo* bar; bar.b = 3; 

क्लैंग कार्यान्वयन एक पुनरावर्ती वंश विश्लेषक का उपयोग करता है:

चूंकि यह नियमित C ++ कोड है, एक पुनरावर्ती वंश शुरुआती लोगों के लिए इसे समझना आसान बनाता है। यह कस्टम नियमों और अन्य अजीब चीजों का समर्थन करता है जिन्हें C / C ++ की आवश्यकता होती है और आपको त्रुटियों का आसानी से निदान और निदान करने में मदद करता है।

यह अन्य दृष्टिकोणों पर भी ध्यान देने योग्य है:

• अवरोही एलएल, पुनरावर्ती वंश
• आरोही, शिफ्ट, आरोही वंश

पार्सर जनरेटर

एक और अच्छा तरीका है। बेशक, इसके नुकसान भी हैं - लेकिन यह किसी अन्य विकल्प के बारे में कहा जा सकता है जो प्रोग्रामर सॉफ़्टवेयर बनाते समय बनाते हैं।

पार्सर जेनरेटर बहुत तेज गति से काम करते हैं। उनका उपयोग करना अपने स्वयं के विश्लेषक लिखने और गुणवत्ता परिणाम प्राप्त करने की तुलना में आसान है - हालांकि वे बहुत उपयोगकर्ता के अनुकूल नहीं हैं और हमेशा त्रुटि संदेश प्रदर्शित नहीं करते हैं। इसके अलावा, आपको सीखना होगा कि पार्सर जनरेटर का उपयोग कैसे करें, और संकलक को बढ़ावा देते समय, आपको संभवतः पार्सर जनरेटर को खोलना होगा।

पार्सर जनरेटर का एक उदाहरण ANTLR है , कई अन्य हैं।

मुझे लगता है कि यह उपकरण उन लोगों के लिए उपयुक्त है जो फ्रंटएंड लिखने में समय बिताना नहीं चाहते हैं, और जो कंपाइलर / दुभाषिया के मध्य और बैकेंड को लिखना और कुछ भी विश्लेषण करना पसंद करेंगे।

पार्सिंग एप्लीकेशन

यदि आप अभी भी खुद को नहीं समझते हैं। यहां तक ​​कि कंपाइलर फ्रंटेंड (lex / parse) का उपयोग अन्य समस्याओं को हल करने के लिए किया जा सकता है:

• वाक्य रचना हाइलाइटिंग
• HTML / CSS प्रतिपादन इंजन के लिए पार्सिंग
• ट्रांसपिलर: टाइपस्क्रिप्ट, कॉफीस्क्रिप्ट
• linkers
• REGEX
• इंटरफ़ेस डेटा विश्लेषण
• URL पार्सिंग
• प्रारूपण उपकरण जैसे gofmt
• SQL पार्सिंग और बहुत कुछ।

बीच

शब्दार्थ विश्लेषण! कंपाइलर बनाते समय भाषा के शब्दार्थ का विश्लेषण सबसे कठिन कार्यों में से एक है।

आपको यह सुनिश्चित करने की आवश्यकता है कि सभी इनपुट प्रोग्राम सही तरीके से काम करते हैं। मेरी क्रुग भाषा में, शब्दार्थ विश्लेषण से संबंधित पहलुओं को अभी तक शामिल नहीं किया गया है, और इसके बिना, प्रोग्रामर को हमेशा सही कोड लिखने की आवश्यकता होगी। वास्तव में, यह असंभव है - और हम हमेशा लिखते हैं, संकलन करते हैं, कभी-कभी चलाते हैं, त्रुटियों को सही करते हैं। यह सर्पिल अंतहीन है।

इसके अलावा, संकलन के उचित चरण में शब्दार्थ की शुद्धता के विश्लेषण के बिना कार्यक्रमों का संकलन असंभव है।

मैं एक बार फ्रंट-एंड, मिड -लैंड और बैकएंड के प्रतिशत के बारे में एक चार्ट में आया था। फिर ऐसा लग रहा था

 F: 20% M: 20%: B: 60% 

आज यह कुछ ऐसा है

 F: 5% M: 60% B: 35% 

सीमांत मुख्य रूप से जनरेटर से संबंधित है, और ऐसे संदर्भहीन भाषाओं में, जिनमें व्याकरण का द्वंद्व नहीं है, उन्हें काफी जल्दी पूरा किया जा सकता है - एक पुनरावर्ती वंश यहां मदद करेगा।

एलएलवीएम तकनीक के साथ, अधिकांश अनुकूलन कार्य को फ्रेमवर्क में अपलोड किया जा सकता है, जो कई तैयार अनुकूलन प्रस्तुत करता है।

अगला चरण शब्दार्थ विश्लेषण है, संकलन चरण का एक अनिवार्य हिस्सा है।

उदाहरण के लिए, रस्ट में, अपने मेमोरी मैनेजमेंट मॉडल के साथ, कंपाइलर एक बड़ी, शक्तिशाली मशीन के रूप में कार्य करता है जो परिचयात्मक रूपों पर विभिन्न प्रकार के स्थैतिक विश्लेषण करता है। इस कार्य का एक हिस्सा इनपुट डेटा को विश्लेषण के लिए अधिक सुविधाजनक रूप में परिवर्तित करना है।

इस कारण से, सिमेंटिक विश्लेषण कंपाइलर की वास्तुकला में एक महत्वपूर्ण भूमिका निभाता है, और तैयारी के काम को समाप्त करता है, जैसे उत्पन्न विधानसभा को अनुकूलित करना या एएसडी में इनपुट डेटा को पढ़ना, आपके लिए किया जाता है।

शब्दार्थ मार्ग

सिमेंटिक विश्लेषण के दौरान, अधिकांश कंपाइलर एसडीए या कोड एब्स्ट्रैक्ट के अन्य अमूर्त रूप पर बड़ी संख्या में "सिमेंटिक पास" का संचालन करते हैं। यह आलेख .NET C # संकलक में किए गए अधिकांश पासों के बारे में विवरण प्रदान करता है।

मैं प्रत्येक मार्ग पर विचार नहीं करूंगा, खासकर जब से वे भाषा के आधार पर भिन्न होते हैं, लेकिन क्रुग में नीचे कई चरणों का वर्णन किया गया है।

शीर्ष स्तर का विज्ञापन

कंपाइलर मॉड्यूल में सभी "शीर्ष-स्तरीय" घोषणाओं के माध्यम से जाएगा और उनके अस्तित्व के बारे में जागरूक होगा। वह ब्लॉकों में गहराई तक नहीं जाएगा - वह बस यह घोषित करेगा कि कौन सी संरचनाएं, कार्य आदि। एक या दूसरे मॉड्यूल में उपलब्ध हैं।

नाम / प्रतीक संकल्प

संकलक कार्यों में कोड के सभी ब्लॉकों से गुजरता है, आदि। और उन्हें हल करता है - अर्थात्, उन पात्रों को पाता है जिन्हें अनुमति की आवश्यकता होती है। यह एक सामान्य पास है, और यह यहाँ से है कि नो कोड प्रतीक XYZ त्रुटि आमतौर पर गो कोड संकलित करते समय आती है।

इस पास को करना बहुत मुश्किल हो सकता है, खासकर अगर आपके निर्भरता आरेख में परिपत्र निर्भरताएं हैं। उदाहरण के लिए, कुछ भाषाएं उन्हें अनुमति नहीं देती हैं, यदि आपके संकुल में से एक लूप बनता है, तो मेरी त्रुटि है, जैसे कि मेरी क्रुग भाषा। चक्रीय निर्भरता को खराब वास्तुकला का एक साइड इफेक्ट माना जा सकता है।

निर्भरता आरेख में डीएफएस को संशोधित करके, या टारजन एल्गोरिथ्म (जैसा कि क्रग द्वारा किया जाता है) को परिभाषित करने के लिए (कई) लूप का उपयोग करके लूप निर्धारित किए जा सकते हैं।

प्रकार का आविष्कार

संकलक सभी चर के माध्यम से जाता है और उनके प्रकार प्रदर्शित करता है। क्रुग में टाइप इंफ़ेक्शन बहुत कमजोर है, यह बस उनके मूल्यों के आधार पर चर का उत्पादन करता है। यह किसी भी तरह से एक विचित्र प्रणाली नहीं है, जैसे कि आप हास्केल जैसी कार्यात्मक भाषाओं में पा सकते हैं।

प्रकार "एकीकरण" प्रक्रिया, या "प्रकार एकीकरण" का उपयोग करके प्राप्त किया जा सकता है। सरल प्रकार की प्रणालियों के लिए, एक बहुत ही सरल कार्यान्वयन का उपयोग किया जा सकता है।

क्रुग में इस प्रकार लागू होते हैं:

 interface Type {}; struct IntegerType : Type { int width; bool signed; }; struct FloatingType : Type { int width; }; struct ArrayType : Type { Type base_type; uint64 length; }; 

आपके पास एक साधारण प्रकार का निष्कर्ष भी हो सकता है, जिसमें आप एक प्रकार का अभिव्यक्ति नोड देते हैं, उदाहरण के लिए, IntegerConstantNode प्रकार का हो सकता है IntegerType (64)। और फिर आपको unify(t1, t2) फंक्शन मिल सकता है, जो कि उस सबसे बड़े प्रकार का चयन करेगा, जिसका उपयोग अधिक जटिल अभिव्यक्तियों के प्रकार, बाइनरी, का उपयोग करने के लिए किया जा सकता है। तो यह दाईं ओर दिए गए प्रकारों के मूल्यों के बाईं ओर एक चर निर्दिष्ट करने की बात है।

मैंने एक बार गो पर एक साधारण टाइप कास्ट लिखा था, जो क्रुग के लिए एक प्रोटोटाइप कार्यान्वयन बन गया।

उत्परिवर्तन दर

क्रुग (जैसे जंग) डिफ़ॉल्ट रूप से एक अपरिवर्तनीय भाषा है, अर्थात, जब तक अन्यथा निर्दिष्ट न हो, चर अपरिवर्तित रहें:

 let x = 3; x = 4; // BAD! mut y = 5; y = 6; // OK! 

संकलक सभी ब्लॉकों और कार्यों से गुजरता है और जांचता है कि उनके "चर सही हैं", अर्थात्, हम जो परिवर्तन नहीं करते हैं, उसका परिवर्तन नहीं करते हैं, और यह कि कुछ कार्यों के लिए पारित सभी चर निरंतर या परिवर्तनशील होते हैं जहां आवश्यकता होती है।

यह प्रतीकात्मक जानकारी की मदद से किया जाता है जिसे पिछले पासों पर एकत्र किया गया है। सिमेंटिक पास के परिणामों के आधार पर एक प्रतीक तालिका में परिवर्तनीय परिवर्तनशीलता के टोकन नाम और संकेत शामिल हैं। इसमें अन्य डेटा शामिल हो सकते हैं, उदाहरण के लिए, C ++ में एक तालिका इस बारे में जानकारी संग्रहीत कर सकती है कि कोई प्रतीक बाहरी है या स्थिर है।

चरित्र तालिका

एक चरित्र तालिका, या "छुरा", उन पात्रों को खोजने के लिए एक तालिका है जो आपके कार्यक्रम में उपयोग किए जाते हैं। प्रत्येक क्षेत्र के लिए एक तालिका बनाई गई है, और उन सभी में किसी विशेष दायरे में मौजूद वर्णों के बारे में जानकारी है।

इस जानकारी में प्रतीक नाम, प्रकार, परिवर्तनशीलता का संकेत, बाहरी संचार की उपस्थिति, स्थिर स्मृति में स्थान और इसी तरह के गुण शामिल हैं।

क्षेत्र

प्रोग्रामिंग भाषाओं में यह एक महत्वपूर्ण अवधारणा है। बेशक, आपकी भाषा को नेस्टेड स्कोप बनाने के लिए संभव नहीं है, सब कुछ एक सामान्य नाम स्थान में रखा जा सकता है!

हालांकि गुंजाइश का प्रतिनिधित्व करना कंपाइलर आर्किटेक्चर के लिए एक दिलचस्प काम है, अधिकांश सी-लाइक भाषाओं में, स्कोप डेटा संरचना की तरह स्कोप व्यवहार करता है (या है)।

आमतौर पर हम स्कोप बनाते हैं और नष्ट करते हैं, और वे आमतौर पर नामों को प्रबंधित करने के लिए उपयोग किए जाते हैं, अर्थात, वे हमें छिपाने (छाया देने) के लिए अनुमति देते हैं:

 { // push scope let x = 3; { // push scope let x = 4; // OK! } // pop scope } // pop scope 

इसे अलग तरह से प्रस्तुत किया जा सकता है:

 struct Scope { Scope* outer; SymbolTable symbols; } 

एक छोटा सा, लेकिन मैं स्पेगेटी स्टैक के बारे में पढ़ने की सलाह देता हूं। यह एक डेटा संरचना है जिसका उपयोग विपरीत क्षेत्रों के एएसडी नोड्स में दृश्यता क्षेत्रों को संग्रहीत करने के लिए किया जाता है।

सिस्टम टाइप करें

निम्न में से कई खंडों को अलग-अलग लेखों में विकसित किया जा सकता है, लेकिन मुझे ऐसा लगता है कि यह शीर्षक इस सबसे योग्य है। आज बहुत सारी जानकारी प्रकार प्रणालियों के बारे में उपलब्ध है, साथ ही साथ स्वयं सिस्टम की किस्में भी हैं, जिनके आसपास कई प्रतियां टूट जाती हैं। मैं इस विषय में गहराई से नहीं उतरूंगा , बस स्टीव क्लेबनिक के उत्कृष्ट लेख की एक कड़ी छोड़ दूंगा ।

एक प्रकार की प्रणाली वह है जो संकलक में इन अभ्यावेदन के विश्लेषण और विश्लेषण का उपयोग करके प्रदान की गई और शब्दार्थ में परिभाषित की गई है।

अधिकार

इस अवधारणा का उपयोग अधिक से अधिक प्रोग्रामिंग में किया जाता है। स्वामित्व और आंदोलन के शब्दार्थ के सिद्धांत रस्ट भाषा में अंतर्निहित हैं, और मुझे आशा है कि वे अन्य भाषाओं में दिखाई देंगे। जंग कई अलग-अलग प्रकार के स्थैतिक विश्लेषण करता है, जो यह देखने के लिए जांचता है कि क्या इनपुट मेमोरी के बारे में नियमों का एक सेट संतुष्ट करता है: कौन स्मृति का मालिक है, कब स्मृति नष्ट हो जाती है, और इन मूल्यों या स्मृति में कितने संदर्भ (या उधार) मौजूद हैं।

रस्ट की सुंदरता इस तथ्य में निहित है कि यह सब संकलन के दौरान, संकलक के अंदर किया जाता है, ताकि प्रोग्रामर को कचरा संग्रह या लिंक गिनती से निपटना न पड़े। ये सभी शब्दार्थ पूरी तरह से बाइनरी फ़ाइल के रूप में प्रस्तुत किए जाने से पहले ही टाइप सिस्टम को दिए जाते हैं और प्रदान किए जा सकते हैं।

मैं यह नहीं कह सकता कि यह सब हुड के तहत कैसे काम करता है, लेकिन यह सब मोज़िला टीम और चक्रवात परियोजना के प्रतिभागियों द्वारा स्थैतिक विश्लेषण और अद्भुत शोध का परिणाम है।

नियंत्रण प्रवाह रेखांकन

कार्यक्रम के प्रवाह का प्रतिनिधित्व करने के लिए, हम नियंत्रण प्रवाह ग्राफ़ (सीएफजी) का उपयोग करते हैं, जिसमें वे सभी पथ होते हैं जो कार्यक्रम निष्पादन का पालन कर सकते हैं। इसका उपयोग शब्दार्थ विश्लेषण में कोड के निष्क्रिय वर्गों, अर्थात, ब्लॉक, फ़ंक्शंस और यहां तक ​​कि उन मॉड्यूल को बाहर करने के लिए किया जाता है जो प्रोग्राम निष्पादन के दौरान कभी प्राप्त नहीं होंगे। ग्राफ़ का उपयोग उन चक्रों की पहचान करने के लिए भी किया जा सकता है जिन्हें बाधित नहीं किया जा सकता है। या दुर्गम कोड की खोज करने के लिए, उदाहरण के लिए, जब आप "घबराहट" कहते हैं (घबराहट कहते हैं), या लूप में वापस आते हैं, और लूप के बाहर कोड निष्पादित नहीं होता है। संकलक के सिमेंटिक चरण के दौरान डेटा प्रवाह विश्लेषण एक महत्वपूर्ण भूमिका निभाता है, इसलिए मैं आपको उन प्रकार के विश्लेषणों के बारे में पढ़ने की सलाह देता हूं जो आप कर सकते हैं, वे कैसे काम करते हैं और क्या अनुकूलन कर सकते हैं।

बैकएंड

हमारी वास्तुकला योजना का अंतिम भाग।

हमने निष्पादन योग्य बायनेरिज़ बनाने के अधिकांश काम किए हैं। यह विभिन्न तरीकों से किया जा सकता है, जिसके बारे में हम नीचे चर्चा करेंगे।

- , . , , «».

, . , , . , , , . , .

, . , ++ — Cfront — C.

JavaScript. TypeScript , , , , .

«» , , , , « » . — , , .

LLVM

LLVM: Rust, Swift, C/C++ (clang), D, Haskell.

« », , . , LLVM . , . , , , , 1, 4, 8 16-. , , - .

-

— , — , .

Go — , LLVM ( ). Go , Windows, Linux MacOS. , Krug -.

. , LLVM, , , LLVM , .

, , , LLVM, IR, , , , ( ).

. , , , . IR ( ) «» fprintf . 8cc .

. — Java: , JVM , , Kotlin.

, Java . , . , .
, JVM JIT , JIT-, .

, ! , , . - , , . Godbolt — , , . , , .

, , (strip the debug symbols), , GCC. , - .

. . , . production-.

rwmj , 8 , 80% . 1971-! , Rust.

IR

(intermediate representation, IR) , . , , .

IR . , , , .

IR, «», IR . , SSA — Static Single Assignment, , .

Go IR SSA. IR LLVM SSA, .

SSA , , (constant propagation), ( ) .

, . , , , , . ( 16 32), , (spill to the stack).

— ( ). , , .

:

• (graph colouring) — (NP- ). , (liveness ranges) .
  
• — .
  

. , . , , .

( Name Mangling )

-, , . , .

 fn main() int { let x = 0; { let x = 0; { let x = 0; } } return 0; } 

, ( - :) ) , . , .

LLDB DWARF . LLVM , DWARF GNU-. , , , .

(Foreign Function Interface, FFI )

libc , , . , ?

— . , ( .s/.asm)? ? , Jai . , .

(CaaS)

API-. , Krug-, . , , .

, , , . , API-.

production- CaaS. Microsofts Roslyn, , . , , , , API-, , , Rust RLS .

Krug — — Caasper CaaS-.

Caasper (, , ), , krug, . , , (bootstrap) , .

Krug JavaScript, Go*, , , Krug. JavaScript , yarn/npm.

* Go () , JS.

Caasper . Github Krug, D LLVM. YouTube- .

Krug () .

उपयोगी लिंक

• Jack Crenshaw — .
  
• Crafting Interpreters
  
• LLVM ( Go) — !
  
• PL/0
  
• The Dragon Book — , .
  
• 8cc