👨🏾‍🔬 🌡️ 🍿 TableGen का उपयोग करके LLVM में प्रोसेसर आर्किटेक्चर का विवरण 🤙 🍾 👨‍🎤

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

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

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

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

.Td फ़ाइल में आर्किटेक्चर का विवरण

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

आधुनिक प्रोसेसर बहुत जटिल सिस्टम हैं, इसलिए यह आश्चर्य की बात नहीं है कि उनका विवरण काफी बड़ा है। तदनुसार, संरचना बनाने के लिए और .td फाइलों के रखरखाव को सरल बनाने के लिए प्रोग्रामर के लिए सामान्य #include निर्देश का उपयोग करके एक दूसरे को शामिल कर सकते हैं। इस निर्देश की सहायता से, Target.td फ़ाइल को हमेशा पहले शामिल किया जाता है, जिसमें प्लेटफ़ॉर्म स्वतंत्र इंटरफेस होते हैं जिन्हें सभी आवश्यक टेबलगैन जानकारी प्रदान करने के लिए लागू किया जाना चाहिए। इस फ़ाइल में एलएलवीएम आंतरिक विवरण के साथ एक .td फ़ाइल पहले से ही शामिल है, लेकिन अपने आप में मुख्य रूप से इसमें आधार कक्षाएं शामिल हैं, जैसे Register , Instruction , Processor , आदि, जिसमें से आपको एक कंपाइलर के आधार पर अपनी खुद की वास्तुकला बनाने के लिए विरासत में प्राप्त करना होगा। LLVM। पिछले वाक्य से, यह स्पष्ट है कि टेबलगैन में सभी प्रोग्रामरों के लिए अच्छी तरह से ज्ञात कक्षाओं की धारणा है।

सामान्य तौर पर, TableGen में केवल दो मूल इकाइयाँ होती हैं: कक्षाएं और परिभाषाएँ ।

कक्षाएं

टेबलगैन कक्षाएं भी सार हैं, जैसा कि सभी ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं में है, लेकिन वे सरल इकाइयां हैं।

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

 // A class representing the register size, spill size and spill alignment // in bits of a register. class RegInfo<int RS, int SS, int SA> { int RegSize = RS; // Register size in bits. int SpillSize = SS; // Spill slot size in bits. int SpillAlignment = SA; // Spill slot alignment in bits. }

कोण कोष्ठक इनपुट मापदंडों को इंगित करता है जो वर्ग गुणों को सौंपा गया है। इस उदाहरण से, आप यह भी देख सकते हैं कि TableGen भाषा सांख्यिकीय रूप से टाइप की गई है। TableGen में मौजूद प्रकार: bit (मान 0 और 1 के साथ बूलियन प्रकार का एक एनालॉग), int , string , code ( code एक टुकड़ा, यह एक प्रकार है, बस क्योंकि TableGen में सामान्य अर्थों में तरीके और कार्य नहीं होते हैं, कोड की पंक्तियाँ [{ ... }] में लिखी जाती हैं [{ ... }] ), बिट्स <n>, सूची <प्रकार> (मान वर्ग कोष्ठक [...] के रूप में पायथन और कुछ अन्य प्रोग्रामिंग भाषाओं में उपयोग किए जाते हैं), class type , dag ।

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

वंशानुक्रम भी एक काफी परिचित वाक्यविन्यास द्वारा वर्णित है :

 class X86MemOperand<string printMethod, AsmOperandClass parserMatchClass = X86MemAsmOperand> : Operand<iPTR> { let PrintMethod = printMethod; let MIOperandInfo = (ops ptr_rc, i8imm, ptr_rc_nosp, i32imm, SEGMENT_REG); let ParserMatchClass = parserMatchClass; let OperandType = "OPERAND_MEMORY"; }

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

परिभाषाएं (परिभाषाओं)

परिभाषाएं पहले से ही ठोस हैं, आप उनकी तुलना सभी वस्तुओं से कर सकते हैं। परिभाषाएँ परिभाषित कीवर्ड का उपयोग करके परिभाषित की जाती हैं और ऊपर बताए अनुसार ठीक उसी तरह से आधार कक्षाओं के एक वर्ग को फिर से परिभाषित कर सकती हैं, और उनके अपने क्षेत्र भी हो सकते हैं।

 def i8mem : X86MemOperand<"printbytemem", X86Mem8AsmOperand>; def X86AbsMemAsmOperand : AsmOperandClass { let Name = "AbsMem"; let SuperClasses = [X86MemAsmOperand]; }

Multiclasses (multiclasses)

स्वाभाविक रूप से, प्रोसेसर में बड़ी संख्या में निर्देशों में समान शब्दार्थ होते हैं। उदाहरण के लिए, तीन-पतों के निर्देशों का एक सेट हो सकता है जो दो रूपों “reg = reg op reg” और “reg = reg op imm” । एक मामले में, रजिस्टरों से मान लिया जाता है और परिणाम रजिस्टर में भी सहेजा जाता है, और दूसरे मामले में, दूसरा ऑपरेंड एक निरंतर मूल्य (अपर - तत्काल ऑपरेंड) होता है।

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

 multiclass ri_inst<int opc, string asmstr> { def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"), (ops GPR:$dst, GPR:$src1, GPR:$src2)>; def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"), (ops GPR:$dst, GPR:$src1, Imm:$src2)>; }

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

 // Instantiations of the ri_inst multiclass. defm ADD : ri_inst<0b111, "add">; defm SUB : ri_inst<0b101, "sub">; defm MUL : ri_inst<0b100, "mul">;

और परिणामस्वरूप, defm माध्यम से दी गई ऐसी प्रत्येक परिभाषा के लिए defm वास्तव में, कई परिभाषाओं का निर्माण किया जाएगा जो कि मुख्य निर्देश और मल्टीकालेज़ में वर्णित सभी संभावित रूपों का एक संयोजन हैं। परिणामस्वरूप, इस उदाहरण में निम्नलिखित निर्देश उत्पन्न होंगे: ADD_rr , ADD_ri , SUB_rr , SUB_ri , MUL_rr , MUL_ri ।

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

Subtargets

प्रोसेसर के लिए एक और बुनियादी और उपयोगी चीज जिसमें निर्देश सेट के विभिन्न रूप हैं, एलएलवीएम में सबटार्गेट का समर्थन है। उपयोग का एक उदाहरण LLVM SPARC कार्यान्वयन है, जो एक ही बार में SPARC माइक्रोप्रोसेसर आर्किटेक्चर के तीन मुख्य संस्करणों को शामिल करता है: संस्करण 8 (V8, 32-बिट आर्किटेक्चर), संस्करण 9 (V9, 64-बिट आर्किटेक्चर) और UltraSPARC आर्किटेक्चर। आर्किटेक्चर के बीच का अंतर काफी बड़ा है, विभिन्न प्रकार के रजिस्टरों की एक अलग संख्या, समर्थित बाइट ऑर्डर, आदि। ऐसे मामलों में, यदि कई कॉन्फ़िगरेशन हैं, तो यह आर्किटेक्चर के लिए XXXSubtarget वर्ग को लागू करने के लायक है। विवरण में इस वर्ग का उपयोग करने के परिणामस्वरूप नए कमांड लाइन विकल्प -mcpu= और -mattr= ।

Subtarget क्लास के अलावा, Subtarget क्लास महत्वपूर्ण है।

 class SubtargetFeature<string n, string a, string v, string d, list<SubtargetFeature> i = []> { string Name = n; string Attribute = a; string Value = v; string Desc = d; list<SubtargetFeature> Implies = i; }

Sparc.td फ़ाइल में, आप Sparc.td के कार्यान्वयन के उदाहरण पा सकते हैं, जो आपको वास्तुकला के प्रत्येक व्यक्ति के उपप्रकार के लिए निर्देशों के एक सेट की उपलब्धता का वर्णन करने की अनुमति देता है।

 def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true", "Enable SPARC-V9 instructions">; def FeatureV8Deprecated : SubtargetFeature<"deprecated-v8", "V8DeprecatedInsts", "true", "Enable deprecated V8 instructions in V9 mode">; def FeatureVIS : SubtargetFeature<"vis", "IsVIS", "true", "Enable UltraSPARC Visual Instruction Set extensions">;

इस मामले में, वैसे भी, Sparc.td अभी भी Proc वर्ग को परिभाषित करता है, जिसका उपयोग SPARC प्रोसेसर के विशिष्ट उपप्रकारों का वर्णन करने के लिए किया जाता है, जिसमें बस ऊपर वर्णित गुण हो सकते हैं, जिसमें निर्देशों के विभिन्न सेट शामिल हैं।

 class Proc<string Name, list<SubtargetFeature> Features> : Processor<Name, NoItineraries, Features>; def : Proc<"generic", []>; def : Proc<"v8", []>; def : Proc<"supersparc", []>; def : Proc<"sparclite", []>; def : Proc<"f934", []>; def : Proc<"hypersparc", []>; def : Proc<"sparclite86x", []>; def : Proc<"sparclet", []>; def : Proc<"tsc701", []>; def : Proc<"v9", [FeatureV9]>; def : Proc<"ultrasparc", [FeatureV9, FeatureV8Deprecated]>; def : Proc<"ultrasparc3", [FeatureV9, FeatureV8Deprecated]>; def : Proc<"ultrasparc3-vis", [FeatureV9, FeatureV8Deprecated, FeatureVIS]>;

टेबलगेन और एलएलवीएम बैकएंड कोड में निर्देशों के गुणों के बीच संबंध

कक्षाओं और परिभाषाओं के गुण आपको वास्तु सुविधाओं को सही ढंग से उत्पन्न करने और सेट करने की अनुमति देते हैं, लेकिन एलएलवीएम बैकएंड स्रोत कोड से उनकी कोई सीधी पहुंच नहीं है। हालाँकि, कभी-कभी आप संकलक कोड में निर्देशों के कुछ प्लेटफ़ॉर्म-विशिष्ट गुण प्राप्त करने में सक्षम होना चाहते हैं।

TSFlags

ऐसा करने के लिए, Instruction बेस क्लास में एक विशेष क्षेत्र है, 64-बिट TSFlags, जिसे TableGen द्वारा परिवर्तित किया जाता है, जो TableGen विवरण से प्राप्त आंकड़ों के आधार पर, वर्ग MCInstrDesc के C ++ ऑब्जेक्ट के एक क्षेत्र में उत्पन्न होता है। आप किसी भी संख्या में बिट्स निर्दिष्ट कर सकते हैं जिन्हें आपको जानकारी संग्रहीत करने की आवश्यकता है। यह कुछ बूलियन मान हो सकता है, उदाहरण के लिए, यह इंगित करने के लिए कि हम एक स्केलर ALU का उपयोग कर रहे हैं।

 let TSFlags{0} = SALU;

या हम निर्देश के प्रकार को संग्रहीत कर सकते हैं। फिर, हमें निश्चित रूप से, एक से अधिक बिट की आवश्यकता है।

 // Instruction type according to the ISA. IType Type = type; let TSFlags{7-1} = Type.Value;

परिणामस्वरूप, बैकेंड कोड में इन गुणों को निर्देश से प्राप्त करना संभव हो जाता है।

 bool isSALU = MI.getDesc().TSFlags & SIInstrFlags::SALU;

यदि संपत्ति अधिक जटिल है, तो आप इसे TableGen में वर्णित मूल्य के साथ तुलना कर सकते हैं, जिसे ऑटो-जनरेट किए गए प्रेषण में जोड़ा जाएगा।

 (Desc.TSFlags & X86II::FormMask) == X86II::MRMSrcMem

कार्य की भविष्यवाणी करता है

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

 // Base class for function predicates. class FunctionPredicateBase<string name, MCStatement body> { string FunctionName = name; MCStatement Body = body; }

आप X86 के बैकएंड में उपयोग के उदाहरण आसानी से पा सकते हैं। तो इसका अपना मध्यवर्ती वर्ग है, जिसकी सहायता से कार्यों की आवश्यक परिभाषाएँ पहले से ही निर्मित हैं।

 // Check that a call to method `Name` in class "XXXInstrInfo" (where XXX is // the name of a target) returns true. // // TIIPredicate definitions are used to model calls to the target-specific // InstrInfo. A TIIPredicate is treated specially by the InstrInfoEmitter // tablegen backend, which will use it to automatically generate a definition in // the target specific `InstrInfo` class. // // There cannot be multiple TIIPredicate definitions with the same name for the // same target class TIIPredicate<string Name, MCStatement body> : FunctionPredicateBase<Name, body>, MCInstPredicate; // This predicate evaluates to true only if the input machine instruction is a // 3-operands LEA. Tablegen automatically generates a new method for it in // X86GenInstrInfo. def IsThreeOperandsLEAFn : TIIPredicate<"isThreeOperandsLEA", IsThreeOperandsLEABody>; //   -    ,  -  ,       // Used to generate the body of a TII member function. def IsThreeOperandsLEABody : MCOpcodeSwitchStatement<[LEACases], MCReturnStatement<FalsePred>>;

परिणामस्वरूप, आप C ++ कोड में isThreeOperandsLEA विधि का उपयोग कर सकते हैं।

 if (!(TII->isThreeOperandsLEA(MI) || hasInefficientLEABaseReg(Base, Index)) || !TII->isSafeToClobberEFLAGS(MBB, MI) || Segment.getReg() != X86::NoRegister) return;

यहाँ TII लक्ष्य निर्देश सूचना है, जिसे वांछित आर्किटेक्चर के लिए MCSubtargetInfo से getInstrInfo() विधि का उपयोग करके प्राप्त किया जा सकता है।

अनुकूलन के दौरान निर्देशों का परिवर्तन। निर्देश मानचित्रण

संकलन के बाद के चरणों में बड़ी संख्या में किए गए अनुकूलन के दौरान, कार्य अक्सर एक फॉर्म के निर्देशों के सभी या केवल एक भाग को दूसरे रूप के निर्देशों में परिवर्तित करने के लिए उत्पन्न होता है। शुरुआत में वर्णित बहुरंगी के आवेदन को देखते हुए, हमारे पास समान शब्दार्थ और गुणों के साथ बड़ी संख्या में निर्देश हो सकते हैं। कोड में, इन परिवर्तनों को, निश्चित रूप से बड़े switch-case निर्माण के रूप में लिखा जा सकता है, जिसने प्रत्येक निर्देश के लिए संबंधित परिवर्तन को कुचल दिया। आंशिक रूप से, इन विशाल निर्माणों को मैक्रोज़ की मदद से कम किया जा सकता है, जो कि प्रसिद्ध नियमों के अनुसार निर्देश का आवश्यक नाम होगा। लेकिन फिर भी, यह दृष्टिकोण बहुत असुविधाजनक है, इस तथ्य के कारण बनाए रखना मुश्किल है कि सभी निर्देश नाम स्पष्ट रूप से सूचीबद्ध हैं। एक नया निर्देश जोड़ने से बहुत आसानी से त्रुटि हो सकती है, क्योंकि आपको इसे सभी प्रासंगिक रूपांतरणों में जोड़ना होगा। इस दृष्टिकोण से पीड़ित होने के बाद, एलएलवीएम ने निर्देश के एक रूप को दूसरे Instruction Mapping में कुशलता से परिवर्तित करने के लिए एक विशेष तंत्र बनाया।

यह विचार बहुत सरल है, टेबलगन में सीधे निर्देशों को बदलने के लिए संभव मॉडल का वर्णन करना आवश्यक है। इसलिए, एलएलवीएम टेबलगैन में ऐसे मॉडल का वर्णन करने के लिए एक आधार वर्ग है।

 class InstrMapping { // Used to reduce search space only to the instructions using this // relation model. string FilterClass; // List of fields/attributes that should be same for all the instructions in // a row of the relation table. Think of this as a set of properties shared // by all the instructions related by this relationship. list<string> RowFields = []; // List of fields/attributes that are same for all the instructions // in a column of the relation table. list<string> ColFields = []; // Values for the fields/attributes listed in 'ColFields' corresponding to // the key instruction. This is the instruction that will be transformed // using this relation model. list<string> KeyCol = []; // List of values for the fields/attributes listed in 'ColFields', one for // each column in the relation table. These are the instructions a key // instruction will be transformed into. list<list<string> > ValueCols = []; }

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

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

 class PredRel; multiclass MyInstruction<string name> { let BaseOpcode = name in { def : PredRel { let PredSense = ""; } def _pt: PredRel { let PredSense = "true"; } def _pf: PredRel { let PredSense = "false"; } } } defm ADD: MyInstruction<”ADD”>; defm SUB: MyIntruction<”SUB”>; defm MUL: MyInstruction<”MUL”>; …

इस उदाहरण में, यह भी दिखाया गया है कि कैसे एक बार में एक का उपयोग करते हुए कई परिभाषाओं के लिए एक संपत्ति को ओवरराइड करना है let … in निर्माण में। नतीजतन, हमारे पास कई निर्देश हैं जो उनके आधार नाम और संपत्ति को संग्रहीत करते हैं जो विशिष्ट रूप से उनके रूप का वर्णन करते हैं। तब आप एक परिवर्तन मॉडल बना सकते हैं।

 def getPredOpcode : InstrMapping { // ,       - PredRel  let FilterClass = "PredRel"; //         ,      let RowFields = ["BaseOpcode"]; //          PredSense. let ColFields = ["PredSense"]; //  ,  ,       ,     PredSense=”” let KeyCol = [""]; //   PredSense      let ValueCols = [["true"], ["false"]]; }

परिणामस्वरूप, इस विवरण से निम्न तालिका उत्पन्न की जाएगी।

PredSense = ""	PredSense = "सच"	PredSense = "गलत"
जोड़ें	ADD_pt	ADD_pf
उप	SUB_pt	SUB_pf
एमयूएल	MUL_pt	MUL_pf

.inc फ़ाइल में एक फ़ंक्शन उत्पन्न होगा

 int getPredOpcode(uint16_t Opcode, enum PredSense inPredSense)

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

और बैकएंड कोड में, switch-case लिखने के बजाय switch-case केवल उत्पन्न फ़ंक्शन को कॉल करने के लिए पर्याप्त है, जो परिवर्तित निर्देश के कोड को वापस कर देगा। एक सरल समाधान, जहां नए निर्देश जोड़ने से अतिरिक्त कार्रवाई की आवश्यकता नहीं होगी।

स्वतः-निर्मित कलाकृतियाँ ( `.inc` फ़ाइलें)

TableGen विवरण और LLVM बैकएंड कोड के बीच सभी इंटरैक्शन C कोड वाली उत्पन्न .inc फ़ाइलों द्वारा सुनिश्चित किया जाता है। एक पूरी तस्वीर पाने के लिए, आइए देखें कि वे वास्तव में क्या हैं।

प्रत्येक आर्किटेक्चर के बाद, प्रत्येक आर्किटेक्चर के लिए, बिल्ड डायरेक्टरी में कई .inc फाइलें .inc , जिनमें से प्रत्येक आर्किटेक्चर के बारे में अलग-अलग जानकारी संग्रहीत करती है।तो वहाँ एक फाइल है <TargetName>GenInstrInfo.incनिर्देशों के बारे में जानकारी युक्त <TargetName>GenRegisterInfo.incजो रजिस्टरों बारे में जानकारी शामिल है, क्रमशः, वहाँ कोडांतरक और इसके उत्पादन के साथ सीधे काम करने के लिए फ़ाइलें हैं <TargetName>GenAsmMatcher.incऔर <TargetName>GenAsmWriter.incआदि

तो इन फ़ाइलों से क्या बनता है? सामान्य तौर पर, वे गणना, सरणियाँ, संरचनाएं और सरल कार्य करते हैं। उदाहरण के लिए, आप निर्देश में परिवर्तित जानकारी को देख सकते हैं <TargetName>GenInstrInfo.inc।

पहले भाग में, लक्ष्य के नाम के साथ नामस्थान में एक गणना है जिसमें वर्णित सभी निर्देश हैं।

 namespace X86 { enum { PHI = 0, … ADD16i16 = 287, ADD16mi = 288, ADD16mi8 = 289, ADD16mr = 290, ADD16ri = 291, ADD16ri8 = 292, ADD16rm = 293, ADD16rr = 294, ADD16rr_REV = 295, … }

अगला एक सरणी है जो निर्देशों के गुणों का वर्णन करता है const MCInstrDesc X86Insts[]। निम्नलिखित सरणियों में निर्देश नाम आदि के बारे में जानकारी होती है। मूल रूप से, सभी जानकारी स्थानांतरण और सरणियों में संग्रहीत की जाती है।

ऐसे कार्य भी हैं जिनका वर्णन विधेय का उपयोग करके किया गया है। पिछले अनुभाग में चर्चा की गई फ़ंक्शन की भविष्यवाणी परिभाषा के आधार पर, निम्नलिखित फ़ंक्शन उत्पन्न होगा।

 bool X86InstrInfo::isThreeOperandsLEA(const MachineInstr &MI) { switch(MI.getOpcode()) { case X86::LEA32r: case X86::LEA64r: case X86::LEA64_32r: case X86::LEA16r: return ( MI.getOperand(1).isReg() && MI.getOperand(1).getReg() != 0 && MI.getOperand(3).isReg() && MI.getOperand(3).getReg() != 0 && ( ( MI.getOperand(4).isImm() && MI.getOperand(4).getImm() != 0 ) || (MI.getOperand(4).isGlobal()) ) ); default: return false; } // end of switch-stmt }

लेकिन उत्पन्न फ़ाइलों और संरचनाओं में डेटा हैं। जैसा कि X86GenSubtargetInfo.incआप एक संरचना है कि बैकएंड कोड में इस्तेमाल किया जाना चाहिए इसके माध्यम से वास्तुकला के बारे में जानकारी प्राप्त करने के लिए, पिछले अनुभाग में और एक TTI प्राप्त करता है का एक उदाहरण मिल सकते हैं।

 struct X86GenMCSubtargetInfo : public MCSubtargetInfo { X86GenMCSubtargetInfo(const Triple &TT, StringRef CPU, StringRef FS, ArrayRef<SubtargetFeatureKV> PF, ArrayRef<SubtargetSubTypeKV> PD, const MCWriteProcResEntry *WPR, const MCWriteLatencyEntry *WL, const MCReadAdvanceEntry *RA, const InstrStage *IS, const unsigned *OC, const unsigned *FP) : MCSubtargetInfo(TT, CPU, FS, PF, PD, WPR, WL, RA, IS, OC, FP) { } unsigned resolveVariantSchedClass(unsigned SchedClass, const MCInst *MI, unsigned CPUID) const override { return X86_MC::resolveVariantSchedClassImpl(SchedClass, MI, CPUID); } };

यदि Subtargetविभिन्न विन्यासों का वर्णन करने के लिए उपयोग किया जाता है XXXGenSubtarget.inc, SubtargetFeatureतो सीपीयू की विशेषताओं और उपप्रकारों को इंगित करने के लिए निरंतर मूल्यों के साथ सरणियों का उपयोग करके वर्णित गुणों के साथ एक गणन बनाया जाएगा , और एक फ़ंक्शन उत्पन्न होगा ParseSubtargetFeaturesजो विकल्प सेट के साथ स्ट्रिंग को संसाधित करता है Subtarget। इसके अलावा, XXXSubtargetबैकएंड कोड में विधि का कार्यान्वयन निम्नलिखित छद्म कोड के अनुरूप होना चाहिए, जिसमें इस फ़ंक्शन का उपयोग करना आवश्यक है:

 XXXSubtarget::XXXSubtarget(const Module &M, const std::string &FS) { // Set the default features // Determine default and user specified characteristics of the CPU // Call ParseSubtargetFeatures(FS, CPU) to parse the features string // Perform any additional operations }

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

निष्कर्ष

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

TableGen का उपयोग करके LLVM में प्रोसेसर आर्किटेक्चर का विवरण