भाग 5/2 Bldg। 1: RocketChip एवेन्यू और फिसलन इंस्ट्रूमेंटेशन ट्रैक का चौराहा

पिछले चार भागों में, आरआईएससी-वी रॉकेट कोर के साथ प्रयोगों के लिए तैयारी की गई थी, अर्थात्, इस कोर को अल्टरटा एफपीजीएएस (अब इंटेल) के साथ एक "गैर-मानक" बोर्ड में पोर्ट कर रहा है। अंत में, पिछले भाग में , यह इस बोर्ड पर लिनक्स चलाने के लिए निकला। क्या आप जानते हैं कि इस सब के बारे में मुझे क्या सूझा? यह तथ्य कि एक ही समय में मुझे कोडांतरक RISC-V, C और स्काला के साथ काम करना था, और उन सभी में, स्काला सबसे निचले स्तर की भाषा थी (क्योंकि प्रोसेसर उस पर लिखा गया है)।

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

अंतिम लक्ष्य QInst के साथ सादृश्य द्वारा तुच्छ AFL जैसे इंस्ट्रूमेंट्स का तुच्छ कार्यान्वयन है, और अलग-अलग निर्देशों का कार्यान्वयन केवल एक उप-उत्पाद है।

यह स्पष्ट है कि RTL कनवर्टर के लिए ओपनसीएल (और एक नहीं) वाणिज्यिक है। मुझे RISC-V के लिए एक समान COPILOT परियोजना के बारे में भी जानकारी मिली, जिसमें समान लक्ष्य (बहुत अधिक उन्नत) हैं, लेकिन कुछ बुरी तरह से गुगली कर रहा है, और इसके अलावा, यह सबसे अधिक संभावना एक वाणिज्यिक उत्पाद भी है। मैं मुख्य रूप से OpenSource समाधानों में दिलचस्पी रखता हूं, लेकिन यदि वे हैं, तो भी इसे स्वयं लागू करने का प्रयास करने में मज़ा है - कम से कम एक सरलीकृत मामले के अध्ययन के रूप में, और फिर यह कैसे जाता है ...

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

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

C को समझना सीखना (वास्तव में, नहीं)

पहले आपको यह समझने की आवश्यकता है कि हम C को कैसे पार्स करेंगे? यह सही है, किसी भी तरह से - यह व्यर्थ नहीं था कि मैंने ईएलएफ फ़ाइलों को पार्स करना सीखा: आपको बस हमारे कोड को सी / रस्ट / कुछ और को एक ईपीपीएफ बाइटकोड में संकलित करने की आवश्यकता है, और पहले से ही इसे पार्स करें। कुछ कठिनाइयाँ इस तथ्य के कारण होती हैं कि स्काला में आप केवल elf.h को नहीं जोड़ सकते हैं और संरचना क्षेत्रों को पढ़ सकते हैं। आप निश्चित रूप से, जेएनएरेटर का उपयोग करने की कोशिश कर सकते हैं - यदि आवश्यक हो, तो वे लाइब्रेरी में बाइंड कर सकते हैं - न केवल संरचनाएं, बल्कि जेएनए के माध्यम से काम करने के लिए कोड भी उत्पन्न करते हैं (जेएनआई के साथ भ्रमित नहीं होने के लिए)। एक वास्तविक प्रोग्रामर के रूप में, मैं अपनी बाइक लिखूंगा और हेडर फ़ाइल से गणना और ऑफसेट स्थिरांक को सावधानीपूर्वक लिखूंगा। परिणाम और मध्यवर्ती संरचनाएं केस कक्षाओं की निम्नलिखित संरचना द्वारा वर्णित हैं:

 sealed trait SectionKind case object RegularSection extends SectionKind case object SymtabSection extends SectionKind case object StrtabSection extends SectionKind case object RelSection extends SectionKind final case class Elf64Header( sectionHeaders: Seq[ByteBuffer], sectionStringTableIndex: Int ) final case class Elf64Section( data: ByteBuffer, linkIndex: Int, infoIndex: Int, kind: SectionKind ) final case class Symbol( name: String, value: Int, size: Int, shndx: Int, isInstrumenter: Boolean ) final case class Relocation( relocatedSection: Int, offset: Int, symbol: Symbol ) final case class BpfInsn( opcode: Int, dst: Int, src: Int, offset: Int, imm: Either[Long, Symbol] ) final case class BpfProg( name: String, insns: Seq[BpfInsn] ) 

मैं विशेष रूप से पार्सिंग प्रक्रिया का वर्णन नहीं करूंगा - यह java.nio.ByteBuffer से सिर्फ एक सुस्त बाइट ट्रांसफर है - सभी दिलचस्प चीजें पहले ही ईएलएफ फाइलों को पार्स करने पर लेख में वर्णित की गई हैं। मैं केवल यह कह सकता हूं कि आपको opcode == 0x18 (रजिस्टर में 64-बिट तात्कालिक मान लोड करना) को सावधानीपूर्वक संभालने की आवश्यकता है, क्योंकि यह एक ही बार में दो 8-बाइट शब्द लेता है (शायद इस तरह के अन्य opcodes हैं, लेकिन मैं उनके साथ अभी तक नहीं आया हूं) , और यह हमेशा स्थानांतरण से जुड़े मेमोरी पते को लोड नहीं कर रहा है, जैसा कि मैंने शुरू में सोचा था। उदाहरण के लिए, __builtin_popcountl ईमानदारी से 64-बिट स्थिर 0x0101010101010101 का उपयोग करता है। मैं डाउनलोड की गई फ़ाइल को पैच करने के साथ "ईमानदार" स्थानांतरण क्यों नहीं कर रहा हूं - क्योंकि मैं वर्णों को प्रतीकात्मक रूप में देखना चाहता हूं (सजा के लिए खेद है), ताकि बाद में COMMON अनुभाग के पात्रों को एक विशेष प्रकार के पते के विशेष हैंडलिंग के साथ बैसाखी का उपयोग किए बिना रजिस्टरों से बदला जा सके (और इसका मतलब है, यहां तक ​​कि निरंतर / गैर-स्थिर UInt साथ नृत्य के साथ)।

हम निर्देशों के एक सेट के अनुसार हार्डवेयर का निर्माण करते हैं

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

EBPF बाइटकोड निष्पादन मॉडल 64-बिट एड्रेसिंग के साथ कुछ प्रकार की रैम को मानता है, साथ ही 16 (या दस) 64-बिट रजिस्टरों का एक सेट है। एक आदिम पुनरावर्ती एल्गोरिदम प्रस्तावित है:

• हम उस संदर्भ से शुरू करते हैं जिसमें निर्देश के r1 और r2 में r2 , बाकी में - शून्य, सभी वैध (अधिक सटीक रूप से, वैधता कोप्रोसेसर निर्देश की "तत्परता" के बराबर है)
• यदि हम एक अंकगणितीय-तार्किक निर्देश देखते हैं, तो हम उसके ऑपरेंड रजिस्टरों को संदर्भ से निकालते हैं, सूची की पूंछ के लिए खुद को बुलाते हैं और उस संदर्भ को जिसमें आउटपुट ऑपरेंड को एक जोड़ी द्वारा प्रतिस्थापित किया जाता है (data1 op data2, valid1 && valid2)
• यदि हम एक शाखा का सामना करते हैं, तो हम बस दोनों शाखाओं का पुनरावर्ती निर्माण करते हैं: यदि शाखा होती है, और यदि नहीं
• अगर हम मेमोरी को लोड करने या सहेजने का सामना करते हैं, तो किसी तरह हम बाहर निकलते हैं: हम स्थानांतरित कॉलबैक निष्पादित करते हैं, यह मानते हुए कि इस निर्देश के निष्पादन के दौरान एक बार valid बयान को वापस नहीं लिया जा सकता है। सेव ऑपरेशन की वैधता और हमारे द्वारा globalValid ध्वज के साथ है, जिसे नियंत्रण वापस करने से पहले सेट किया जाना चाहिए। उसी समय, हमें वेतन वृद्धि और अन्य संशोधनों को सही ढंग से संसाधित करने के लिए सामने की ओर पढ़ना और लिखना चाहिए।

इस प्रकार, संचालन यथासंभव समानांतर किया जाएगा, और चरणों में नहीं। उसी समय, मैं आपको ध्यान देने के लिए कहता हूं कि मेमोरी के एक विशिष्ट बाइट पर सभी कार्यों को स्वाभाविक रूप से पूरी तरह से आदेश दिया जाना चाहिए, अन्यथा परिणाम अप्रत्याशित है, यूबी। यानी *addr += 1 - यह सामान्य है, जब तक पढ़ना पूरा नहीं हो जाता तब तक लिखना बिल्कुल शुरू नहीं होगा (क्योंकि हम अभी भी नहीं जानते कि क्या लिखना है), लेकिन *addr += 1; return *addr; *addr += 1; return *addr; मैंने आम तौर पर शून्य या ऐसा कुछ सुरक्षित रूप से दिया। शायद यह डिबगिंग के लायक होगा (हो सकता है कि यह कुछ अधिक मुश्किल समस्या को छुपाता है), लेकिन अपने आप में इस तरह की अपील किसी भी मामले में एक तथाकथित विचार है, क्योंकि आपको यह ध्यान रखना होगा कि किस पते पर काम पहले ही हो चुका है, लेकिन मेरी इच्छा है valid संभव हो valid वैधानिक मूल्यों को मान्य करें। यह ठीक वैसा ही है जैसा कि निश्चित आकार के वैश्विक चरों के लिए किया जाता है।

नतीजा एक अमूर्त वर्ग BpfCircuitConstructor , जिसके पास कोई कार्यान्वित करने के तरीके नहीं हैं doMemLoad , doMemStore और resolveSymbol :

 trait BpfCircuitConstructor { // ... sealed abstract class LdStType(val lgsize: Int) { val byteSize = 1 << lgsize val bitSize = byteSize * 8 val mask: UInt = if (bitSize == 64) mask64 else ((1l << bitSize) - 1).U } case object u8 extends LdStType(0) case object u16 extends LdStType(1) case object u32 extends LdStType(2) case object u64 extends LdStType(3) def doMemLoad(addr: UInt, tpe: LdStType, valid: Bool): (UInt, Bool) def doMemStore(addr: UInt, tpe: LdStType, data: UInt, valid: Bool): Bool sealed trait Resolved { def asPlainValue: UInt def load(ctx: Context, offset: Int, tpe: LdStType, valid: Bool): LazyData def store(offset: Int, tpe: LdStType, data: UInt, valid: Bool): Bool } def resolveSymbol(sym: BpfLoader.Symbol): Resolved // ... } 

सीपीयू कोर एकीकरण

शुरुआत के लिए, मैंने सरल तरीके से जाने का फैसला किया: मानक RoCC (रॉकेट कस्टम कॉप्रेसर) प्रोटोकॉल का उपयोग करके प्रोसेसर कोर से कनेक्ट करें। जहां तक ​​मैं समझता हूं, यह सभी आरआईएससी-वी-संगत कर्नेल के लिए नहीं, बल्कि केवल रॉकेट और बॉम (बर्कले आउट-ऑफ-ऑर्डर मशीन) के लिए एक नियमित विस्तार है, इसलिए, जब custom0 पर अपस्ट्रीम कार्य को खींचते हैं, तो कोडांतरक custom0 mnemonics उनमें से बाहर निकाल दिया गया - custom3 त्वरक कमांड के लिए जिम्मेदार है।

सामान्य तौर पर, प्रत्येक रॉकेट / BOOM प्रोसेसर कोर में चार RoCC त्वरक हो सकते हैं जो कि विन्यास के माध्यम से जोड़े जाते हैं, कार्यान्वयन उदाहरण भी हैं:

Configs.scala:

 class WithRoccExample extends Config((site, here, up) => { case BuildRoCC => List( (p: Parameters) => { val accumulator = LazyModule(new AccumulatorExample(OpcodeSet.custom0, n = 4)(p)) accumulator }, (p: Parameters) => { val translator = LazyModule(new TranslatorExample(OpcodeSet.custom1)(p)) translator }, (p: Parameters) => { val counter = LazyModule(new CharacterCountExample(OpcodeSet.custom2)(p)) counter }) }) 

इसी कार्यान्वयन LazyRoCC.scala फ़ाइल में है।

त्वरक कार्यान्वयन मेमोरी नियंत्रक से पहले से परिचित दो वर्गों का प्रतिनिधित्व करता है: उनमें से एक इस मामले में LazyRoCC , LazyRoCCModuleImp से दूसरे से विरासत में मिला है। दूसरे वर्ग में एक प्रकार का io पोर्ट है RoCCIO , जिसमें cmd अनुरोध पोर्ट, रिस्पांस पोर्ट, मेम एक्सेस L1D कैश पोर्ट, busy और interrupt आउटपुट और exception इनपुट शामिल हैं। एक पेज टेबल वॉकर पोर्ट और FPUs भी हैं जिनकी हमें अभी तक जरूरत नहीं है (वैसे भी, eBPF में कोई वास्तविक अंकगणित नहीं है)। अब तक मैं इस दृष्टिकोण के साथ कुछ करने की कोशिश करना चाहता हूं, इसलिए मैंने टच interrupt नहीं किया। इसके अलावा, जैसा कि मैं इसे समझता हूं, गैर-कैश्ड मेमोरी एक्सेस के लिए एक टाइललिंक इंटरफ़ेस है, लेकिन अभी के लिए मैं इसे स्पर्श नहीं करूंगा।

क्वेरी आयोजक

इसलिए, हमारे पास कैश एक्सेस करने के लिए एक पोर्ट है, लेकिन केवल एक। एक ही समय में, एक फ़ंक्शन, उदाहरण के लिए, एक चर बढ़ा सकता है (जो, बहुत कम से कम, एक एकल परमाणु ऑपरेशन में बदल सकता है) या यहां तक ​​कि किसी भी तरह इसे लोड करने, अपडेट करने और सहेजने से इसे nontrivially रूपांतरित करें। अंत में, एक एकल निर्देश कई असंबंधित अनुरोध कर सकता है। प्रदर्शन के संदर्भ में शायद यह सबसे अच्छा विचार नहीं है, लेकिन, दूसरी ओर, क्यों नहीं, कहते हैं, तीन शब्दों को लोड करें (जो कि, संभवतः, कैश में पहले से ही हैं), किसी तरह उन्हें संयोजन तर्क के साथ समानांतर में संसाधित करें (तब एक हरा) और परिणाम बचाओ। इसलिए, हमें किसी प्रकार की स्कीम की आवश्यकता है जो कि एकल कैश पोर्ट के समानांतर पहुंच पर प्रभावी रूप से "हल" प्रयास करे।

तर्क लगभग निम्नलिखित होंगे: एक विशिष्ट उप-इंजेक्शन (RoCC के संदर्भ में एक 7-बिट फ़ंक्शनल फ़ील्ड) के कार्यान्वयन की शुरुआत में, क्वेरी सीरियलाइज़र का एक उदाहरण बनाया जाता है (एक वैश्विक मुझे बहुत हानिकारक लगता है, क्योंकि यह उन अनुरोधों के बीच अतिरिक्त निर्भरता का एक गुच्छा बनाता है जिन्हें कभी भी निष्पादित नहीं किया जा सकता है, और) स्क्वैंडर Fmax सबसे अधिक संभावना है)। अगला, प्रत्येक "सेवर" / "लोडर" बनाया गया जो कि धारावाहिक में पंजीकृत है। एक जीवित कतार में, इसलिए बोलने के लिए। प्रत्येक उपाय पर, पंजीकरण आदेश में पहला अनुरोध चुना जाता है - उसे अगले उपाय पर अनुमति दी जाती है। स्वाभाविक रूप से, इस तरह के तर्क को अच्छी तरह से परीक्षणों के साथ कवर करने की आवश्यकता है (मैं वास्तव में अभी तक उनमें से बहुत कुछ नहीं है, इसलिए यह सिर्फ सत्यापन नहीं है, लेकिन कम से कम कुछ समझदारी प्राप्त करने के लिए आवश्यक न्यूनतम सेट)। मैंने PeekPokeTester डिजाइनों के परीक्षण के लिए अधिक या कम आधिकारिक घटक से मानक PeekPokeTester उपयोग किया। मैंने पहले ही एक बार इसका वर्णन किया था ।

परिणाम इस तरह के एक गर्भनिरोधक था:

 class Serializer(isComputing: Bool, next: Bool) { def monotonic(x: Bool): Bool = { val res = WireInit(false.B) val prevRes = RegInit(false.B) prevRes := res && isComputing res := (x || prevRes) && isComputing res } private def noone(bs: Seq[Bool]): Bool = !bs.foldLeft(false.B)(_ || _) private val previousReqs = ArrayBuffer[Bool]() def nextReq(x: Bool): (Bool, Int) = { val enable = monotonic(x) val result = RegInit(false.B) val retired = RegInit(false.B) val doRetire = result && next val thisReq = enable && !retired && !doRetire val reqWon = thisReq && noone(previousReqs) when (isComputing) { when(reqWon) { result := true.B } when(doRetire) { result := false.B retired := true.B } } otherwise { result := false.B retired := false.B } previousReqs += thisReq (result, previousReqs.length - 1) } } 

कृपया ध्यान दें कि यहां डिजिटल सर्किट बनाने की प्रक्रिया में, स्काला कोड को सुरक्षित रूप से निष्पादित किया जाता है। यदि आप एक करीब से देखते हैं, तो आप एक ArrayBuffer भी देख सकते हैं जिसमें सर्किट के टुकड़े ढेर हो गए हैं ( Boolean ArrayBuffer से एक प्रकार है, Bool एक छेनी प्रकार है जो लाइव उपकरण का प्रतिनिधित्व करता है, न कि कुछ बूलियन रनटाइम के लिए जाना जाता है)।

L1D कैश के साथ काम करना

कैश के साथ काम ज्यादातर io.mem.req अनुरोध io.mem.req और io.mem.resp प्रतिक्रिया io.mem.resp माध्यम से होता है। उसी समय, अनुरोध पोर्ट पारंपरिक ready और valid संकेतों से सुसज्जित है: पहला आपको बताता है कि यह अनुरोध स्वीकार करने के लिए तैयार है, दूसरा हम कहते हैं कि अनुरोध तैयार है और पहले से ही सही संरचना है, सामने, valid && resp अनुरोध स्वीकार किया जाता है। ऐसे कुछ इंटरफेस में, सेटिंग के क्षण से लेकर true और उसके बाद के valid && resp बढ़त के सकारात्मक बिंदु तक संकेतों की "गैर-प्रतिक्रिया" की आवश्यकता होती है (यह अभिव्यक्ति सुविधा के लिए fire() विधि का उपयोग करके valid && resp जा सकती है)।

प्रतिक्रिया प्रतिक्रिया पोर्ट, बदले में, केवल एक valid संकेत है, और यह एक घड़ी चक्र में जवाबों को रेक करने के लिए प्रोसेसर की समस्या है: यह "हमेशा तैयार" होता है, धारणा द्वारा, और fire() सिर्फ valid ।

साथ ही, जैसा कि मैंने पहले ही कहा था, जब आप भयानक हों तो आप अनुरोध नहीं कर सकते हैं: आप कुछ नहीं लिख सकते, मुझे नहीं पता कि क्या पढ़ा है, और फिर से पढ़ा गया जो घटाए गए मूल्य के आधार पर बाद में लिखा जाएगा वह भी किसी तरह अजीब है। लेकिन Serializer वर्ग पहले से ही इसे समझता है, लेकिन हम केवल यह संकेत देते हैं कि वर्तमान अनुरोध पहले ही कैश में चला गया है: next = io.mem.req.fire() । यह सब किया जा सकता है यह सुनिश्चित करने के लिए कि "रीडर" में उत्तर केवल तभी अपडेट किया जाता है जब वह वास्तव में आया था - पहले नहीं और बाद में नहीं। इसके लिए एक सुविधाजनक holdUnless विधि है। परिणाम लगभग निम्नलिखित कार्यान्वयन है:

  class Constructor extends BpfCircuitConstructor { val serializer = new Serializer(isComputing, io.mem.req.fire()) override def doMemLoad(addr: UInt, tpe: LdStType, valid: Bool): (UInt, Bool) = { val (doReq, thisTag) = serializer.nextReq(valid) when (doReq) { io.mem.req.bits.addr := addr require((1 << io.mem.req.bits.tag.getWidth) > thisTag) io.mem.req.bits.tag := thisTag.U io.mem.req.bits.cmd := M_XRD io.mem.req.bits.typ := (4 | tpe.lgsize).U io.mem.req.bits.data := 0.U io.mem.req.valid := true.B } val doResp = isComputing && serializer.monotonic(doReq && io.mem.req.fire()) && io.mem.resp.valid && io.mem.resp.bits.tag === thisTag.U && io.mem.resp.bits.cmd === M_XRD (io.mem.resp.bits.data holdUnless doResp, serializer.monotonic(doResp)) } override def doMemStore(addr: UInt, tpe: LdStType, data: UInt, valid: Bool): Bool = { val (doReq, thisTag) = serializer.nextReq(valid) when (doReq) { io.mem.req.bits.addr := addr require((1 << io.mem.req.bits.tag.getWidth) > thisTag) io.mem.req.bits.tag := thisTag.U io.mem.req.bits.cmd := M_XWR io.mem.req.bits.typ := (4 | tpe.lgsize).U io.mem.req.bits.data := data io.mem.req.valid := true.B } serializer.monotonic(doReq && io.mem.req.fire()) } override def resolveSymbol(sym: BpfLoader.Symbol): Resolved = sym match { case BpfLoader.Symbol(symName, _, size, ElfConstants.Elf64_Shdr.SHN_COMMON, false) if size <= 8 => RegisterReference(regs.getOrElseUpdate(symName, RegInit(0.U(64.W)))) } } 

इस वर्ग का एक उदाहरण प्रत्येक उत्पन्न उप-निर्माण के लिए बनाया गया है।

ढेर पर सभी एक वैश्विक चर नहीं है

हम्म, एक मॉडल उदाहरण क्या है? मैं किस प्रदर्शन को सुनिश्चित करना चाहूंगा? बेशक, एएफएल इंस्ट्रूमेंटेशन! यह इस तरह से क्लासिक संस्करण में दिखता है:

 #include <stdint.h> extern uint8_t *__afl_area_ptr; extern uint64_t prev; void inst_branch(uint64_t tag) { __afl_area_ptr[((prev >> 1) ^ tag) & 0xFFFF] += 1; prev = tag; } 

जैसा कि आप देख सकते हैं, इसमें __afl_area_ptr से एक बाइट का कमोबेश लॉजिकल लोडिंग और सेविंग (और उनके बीच एक इन्क्रीमेंट) है, लेकिन यहाँ रजिस्टर __afl_area_ptr भूमिका के लिए कह रहा है!

यही कारण है कि Resolved इंटरफ़ेस की आवश्यकता है: यह या तो एक नियमित मेमोरी एड्रेस को लपेट सकता है या एक रजिस्टर संदर्भ हो सकता है। उसी समय, अब तक मैं केवल आकार में 1, 2, 4 या 8 बाइट्स के स्केलर रजिस्टरों पर विचार करता हूं, जो हमेशा शून्य ऑफसेट पर पढ़े जाते हैं, इसलिए रजिस्टरों के लिए, आप कॉल के आदेश को अपेक्षाकृत शांति से लागू कर सकते हैं। इस मामले में, यह जानना बहुत उपयोगी है कि prev को पहले घटाया जाना चाहिए और सूचकांक की गणना करने के लिए उपयोग किया जाना चाहिए, और उसके बाद ही फिर से लिखा जाएगा।

और अब इंस्ट्रूमेंटेशन

कुछ बिंदु पर, हमें RoCC इंटरफ़ेस के साथ एक अलग और कम या अधिक काम करने वाला त्वरक मिला। अब क्या? प्रोसेसर पाइपलाइन के माध्यम से धकेलते हुए सभी को फिर से लागू करें? मुझे ऐसा प्रतीत हुआ कि कम बैसाखी की जरूरत होगी, यदि निर्देश के निर्देश के समानांतर, स्वचालित रूप से जारी उपयोगिता मान के साथ funct बस सक्रिय हो जाएगा। सिद्धांत रूप में, मुझे इसके लिए खुद को तड़पाना पड़ा: मैंने सिग्नलटैप का उपयोग करना भी सीख लिया, क्योंकि डिबगिंग लगभग अंधा है, और यहां तक ​​कि मामूली बदलाव के बाद पांच मिनट के पुनर्संयोजन के साथ (बूट्रोम बदलने के अपवाद के साथ - वहां सब कुछ तेज है - यह पहले से ही बहुत अधिक है।

नतीजतन, कमांड डिकोडर को घुमाया गया और पाइपलाइन को थोड़ा "सीधा" किया गया, इस तथ्य को ध्यान में रखने के लिए कि मूल निर्देश के बारे में डिकोडर ने जो भी कहा, वह खुद को सक्रिय रूप से सक्रिय नहीं करता है, इसका मतलब यह नहीं है कि आउटपुट रजिस्टर के लिए एक लंबा विलंबित लेखन होगा, जैसा कि डिवीजन ऑपरेशन के दौरान होता है और डेटा कैश याद आती है।

सामान्य तौर पर, एक निर्देश का विवरण एक जोड़ी है ([एक निर्देश को पहचानने के लिए पैटर्न], [प्रोसेसर कोर के डेटा पथ ब्लॉकों को कॉन्फ़िगर करने वाले मूल्यों का सेट])। उदाहरण के लिए, default (अपरिचित निर्देश) इस तरह दिखता है (जैसा कि यह IDecode.scala से लिया गया है, डेस्कटॉप हेबर में यह स्पष्ट रूप से, बदसूरत दिखता है):

 def default: List[BitPat] = // jal renf1 fence.i // val | jalr | renf2 | // | fp_val| | renx2 | | renf3 | // | | rocc| | | renx1 s_alu1 mem_val | | | wfd | // | | | br| | | | s_alu2 | imm dw alu | mem_cmd mem_type| | | | mul | // | | | | | | | | | | | | | | | | | | | | | div | fence // | | | | | | | | | | | | | | | | | | | | | | wxd | | amo // | | | | | | | | scie | | | | | | | | | | | | | | | | | dp List(N,X,X,X,X,X,X,X,X,A2_X, A1_X, IMM_X, DW_X, FN_X, N,M_X, MT_X, X,X,X,X,X,X,X,CSR.X,X,X,X,X) 

... और रॉकेट कोर में एक एक्सटेंशन का एक विशिष्ट विवरण इस तरह से लागू किया गया है:

 class IDecode(implicit val p: Parameters) extends DecodeConstants { val table: Array[(BitPat, List[BitPat])] = Array( BNE-> List(Y,N,N,Y,N,N,Y,Y,N,A2_RS2, A1_RS1, IMM_SB,DW_X, FN_SNE, N,M_X, MT_X, N,N,N,N,N,N,N,CSR.N,N,N,N,N), BEQ-> List(Y,N,N,Y,N,N,Y,Y,N,A2_RS2, A1_RS1, IMM_SB,DW_X, FN_SEQ, N,M_X, MT_X, N,N,N,N,N,N,N,CSR.N,N,N,N,N), BLT-> List(Y,N,N,Y,N,N,Y,Y,N,A2_RS2, A1_RS1, IMM_SB,DW_X, FN_SLT, N,M_X, MT_X, N,N,N,N,N,N,N,CSR.N,N,N,N,N), BLTU-> List(Y,N,N,Y,N,N,Y,Y,N,A2_RS2, A1_RS1, IMM_SB,DW_X, FN_SLTU, N,M_X, MT_X, N,N,N,N,N,N,N,CSR.N,N,N,N,N), BGE-> List(Y,N,N,Y,N,N,Y,Y,N,A2_RS2, A1_RS1, IMM_SB,DW_X, FN_SGE, N,M_X, MT_X, N,N,N,N,N,N,N,CSR.N,N,N,N,N), BGEU-> List(Y,N,N,Y,N,N,Y,Y,N,A2_RS2, A1_RS1, IMM_SB,DW_X, FN_SGEU, N,M_X, MT_X, N,N,N,N,N,N,N,CSR.N,N,N,N,N), // ... 

तथ्य यह है कि RISC-V में (न केवल RocketChip में, बल्कि सिद्धांत रूप में कमांड आर्किटेक्चर में) ISA विभाजन को अनिवार्य सब्मिट I (पूर्णांक संचालन), साथ ही वैकल्पिक M (पूर्णांक गुणन और विभाजन), A (एटॉमिक्स) पर नियमित रूप से समर्थित किया गया है। आदि

नतीजतन, मूल विधि

  def decode(inst: UInt, table: Iterable[(BitPat, List[BitPat])]) = { val decoder = DecodeLogic(inst, default, table) val sigs = Seq(legal, fp, rocc, branch, jal, jalr, rxs2, rxs1, scie, sel_alu2, sel_alu1, sel_imm, alu_dw, alu_fn, mem, mem_cmd, mem_type, rfs1, rfs2, rfs3, wfd, mul, div, wxd, csr, fence_i, fence, amo, dp) sigs zip decoder map {case(s,d) => s := d} this } 

द्वारा प्रतिस्थापित किया गया है

 def decode(inst: UInt, table: Iterable[(BitPat, List[BitPat])], handlers: Seq[OpcodeHandler]) = { val decoder = DecodeLogic(inst, default, table) val sigs=Seq(legal, fp, rocc_explicit, branch, jal, jalr, rxs2, rxs1, scie, sel_alu2, sel_alu1, sel_imm, alu_dw, alu_fn, mem, mem_cmd, mem_type, rfs1, rfs2, rfs3, wfd, mul, div, wxd, csr, fence_i, fence, amo, dp) sigs zip decoder map {case(s,d) => s := d} if (handlers.isEmpty) { handler_rocc := false.B handler_rocc_funct := 0.U } else { val handlerTable: Seq[(BitPat, List[BitPat])] = handlers.map { case OpcodeHandler(pattern, funct) => pattern -> List(Y, BitPat(funct.U)) } val handlerDecoder = DecodeLogic(inst, List(N, BitPat(0.U)), handlerTable) Seq(handler_rocc, handler_rocc_funct) zip handlerDecoder map { case (s,d) => s:=d } } rocc := rocc_explicit || handler_rocc this } 

प्रोसेसर पाइपलाइन में बदलावों में से, सबसे अधिक स्पष्ट, शायद, यह था:

  io.rocc.exception := wb_xcpt && csr.io.status.xs.orR io.rocc.cmd.bits.status := csr.io.status io.rocc.cmd.bits.inst := new RoCCInstruction().fromBits(wb_reg_inst) + when (wb_ctrl.handler_rocc) { + io.rocc.cmd.bits.inst.opcode := 0x0b.U // custom0 + io.rocc.cmd.bits.inst.funct := wb_ctrl.handler_rocc_funct + io.rocc.cmd.bits.inst.xd := false.B + io.rocc.cmd.bits.inst.rd := 0.U + } io.rocc.cmd.bits.rs1 := wb_reg_wdata io.rocc.cmd.bits.rs2 := wb_reg_rs2 

यह स्पष्ट है कि एक्सेलेरेटर के लिए अनुरोध के कुछ मापदंडों को ठीक करने की आवश्यकता है: कोई प्रतिक्रिया रजिस्टर में नहीं लिखी गई है, और funct क्या डिकोडर वापस आया के बराबर है। लेकिन थोड़ा कम स्पष्ट परिवर्तन है: तथ्य यह है कि यह कमांड सीधे त्वरक (उनमें से चार - जो एक है?) पर नहीं जाता है, लेकिन राउटर के लिए, इसलिए आपको यह ढोंग करने की आवश्यकता है कि कमांड में opcode == custom0 (हाँ) प्रक्रिया, और यह ठीक शून्य त्वरक है!)।

निरीक्षण

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

 #include <stdint.h> uint64_t counter; uint64_t funct1(uint64_t x, uint64_t y) { return __builtin_popcountl(x); } uint64_t funct2(uint64_t x, uint64_t y) { return (x + y) * (x - y); } uint64_t instMUL() { counter += 1; *((uint64_t *)0x81005000) = counter; return 0; } 

अब main लाइन में bootrom/sdboot/sd.c को जोड़ें

 #include "/path/to/freedom-u-sdk/riscv-pk/machine/encoding.h" // ... ////    -   RoCC #define STR1(x) #x #define STR(x) STR1(x) #define EXTRACT(a, size, offset) (((~(~0 << size) << offset) & a) >> offset) #define CUSTOMX_OPCODE(x) CUSTOM_##x #define CUSTOM_0 0b0001011 #define CUSTOM_1 0b0101011 #define CUSTOM_2 0b1011011 #define CUSTOM_3 0b1111011 #define CUSTOMX(X, rd, rs1, rs2, funct) \ CUSTOMX_OPCODE(X) | \ (rd << (7)) | \ (0x7 << (7+5)) | \ (rs1 << (7+5+3)) | \ (rs2 << (7+5+3+5)) | \ (EXTRACT(funct, 7, 0) << (7+5+3+5+5)) #define CUSTOMX_R_R_R(X, rd, rs1, rs2, funct) \ asm ("mv a4, %[_rs1]\n\t" \ "mv a5, %[_rs2]\n\t" \ ".word "STR(CUSTOMX(X, 15, 14, 15, funct))"\n\t" \ "mv %[_rd], a5" \ : [_rd] "=r" (rd) \ : [_rs1] "r" (rs1), [_rs2] "r" (rs2) \ : "a4", "a5"); int main(void) { // ... //  RoCC extension write_csr(mstatus, MSTATUS_XS & (MSTATUS_XS >> 1)); //   bootrom       uint64_t res; CUSTOMX_R_R_R(0, res, 0xabcdef, 0x123456, 1); CUSTOMX_R_R_R(0, res, 0xabcdef, 0x123456, 2); // ...     uint64_t x = 1; for (int i = 0; i < 123; ++i) x *= *(volatile uint8_t *)0x80000000; kputc('0' + x % 10); //   !!! // ... } 

write_csr , custom0 - custom3 . , illegal instruction, , , , . define - - , «» binutils customX RocketChip, , , .

sdboot , , .

:

 $ /hdd/trosinenko/rocket-tools/bin/riscv32-unknown-elf-gdb -q -ex "target remote :3333" -ex "set directories bootrom" builds/zeowaa-e115/sdboot.elf Reading symbols from builds/zeowaa-e115/sdboot.elf...done. Remote debugging using :3333 0x0000000000000000 in ?? () (gdb) x/d 0x81005000 0x81005000: 123 (gdb) set variable $pc=0x10000 (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x0000000000010488 in crc16_round (data=<optimized out>, crc=<optimized out>) at sd.c:151 151 crc ^= data; (gdb) x/d 0x81005000 0x81005000: 246 

 $ /hdd/trosinenko/rocket-tools/bin/riscv32-unknown-elf-gdb -q -ex "target remote :3333" -ex "set directories bootrom" builds/zeowaa-e115/sdboot.elf Reading symbols from builds/zeowaa-e115/sdboot.elf...done. Remote debugging using :3333 0x0000000000010194 in main () at sd.c:247 247 CUSTOMX_R_R_R(0, res, 0xabcdef, 0x123456, 1); (gdb) set variable $a5=0 (gdb) set variable $pc=0x10194 (gdb) set variable $a4=0xaa (gdb) display/10i $pc-10 1: x/10i $pc-10 0x1018a <main+46>: sw a3,124(a3) 0x1018c <main+48>: addiw a0,a0,1110 0x10190 <main+52>: mv a4,s0 0x10192 <main+54>: mv a5,a0 => 0x10194 <main+56>: 0x2f7778b 0x10198 <main+60>: mv s0,a5 0x1019a <main+62>: lbu a5,0(a1) 0x1019e <main+66>: addiw a3,a3,-1 0x101a0 <main+68>: mul a2,a2,a5 0x101a4 <main+72>: bnez a3,0x1019a <main+62> (gdb) display/x $a5 2: /x $a5 = 0x0 (gdb) si 0x0000000000010198 247 CUSTOMX_R_R_R(0, res, 0xabcdef, 0x123456, 1); 1: x/10i $pc-10 0x1018e <main+50>: li a0,25 0x10190 <main+52>: mv a4,s0 0x10192 <main+54>: mv a5,a0 0x10194 <main+56>: 0x2f7778b => 0x10198 <main+60>: mv s0,a5 0x1019a <main+62>: lbu a5,0(a1) 0x1019e <main+66>: addiw a3,a3,-1 0x101a0 <main+68>: mul a2,a2,a5 0x101a4 <main+72>: bnez a3,0x1019a <main+62> 0x101a6 <main+74>: li a5,10 2: /x $a5 = 0x4 (gdb) set variable $a4=0xaabc (gdb) set variable $pc=0x10194 (gdb) si 0x0000000000010198 247 CUSTOMX_R_R_R(0, res, 0xabcdef, 0x123456, 1); 1: x/10i $pc-10 0x1018e <main+50>: li a0,25 0x10190 <main+52>: mv a4,s0 0x10192 <main+54>: mv a5,a0 0x10194 <main+56>: 0x2f7778b => 0x10198 <main+60>: mv s0,a5 0x1019a <main+62>: lbu a5,0(a1) 0x1019e <main+66>: addiw a3,a3,-1 0x101a0 <main+68>: mul a2,a2,a5 0x101a4 <main+72>: bnez a3,0x1019a <main+62> 0x101a6 <main+74>: li a5,10 2: /x $a5 = 0x9 

स्रोत कोड