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

पहले, आइए RISC-V के बारे में थोड़ी बात करें और इस आर्किटेक्चर के महत्व के बारे में बात करें, RISC-V टूलकिन को कॉन्फ़िगर करें, और एक सरल C प्रोग्राम को RISC-V हार्डवेयर पर चलाएँ।

सामग्री

RISC-V क्या है?

RISC-V एक नि: शुल्क अनुदेश सेट वास्तुकला है। प्रोजेक्ट की शुरुआत 2010 में बर्कले में कैलिफोर्निया विश्वविद्यालय से हुई। इसकी सफलता में एक महत्वपूर्ण भूमिका कोड की खुलेपन और उपयोग की स्वतंत्रता द्वारा निभाई गई थी, जो कई अन्य आर्किटेक्चर से बहुत अलग थी। एआरएम लें: एक संगत प्रोसेसर बनाने के लिए, आपको $ 1 मिलियन से $ 10 मिलियन का अग्रिम शुल्क देना होगा, और बिक्री पर 0.5 royal2% की रॉयल्टी का भुगतान भी करना होगा । एक स्वतंत्र और खुला मॉडल आरआईएससी-वी को कई लोगों के लिए एक आकर्षक विकल्प बनाता है, जिसमें स्टार्टअप के लिए जो एआरएम या अन्य प्रोसेसर के लिए लाइसेंस का भुगतान नहीं कर सकते हैं, अकादमिक शोधकर्ताओं के लिए और (जाहिर है) खुले स्रोत समुदाय के लिए।

आरआईएससी-वी की लोकप्रियता में तेजी से वृद्धि पर किसी का ध्यान नहीं गया। एआरएम ने आरआईएससी-वी (साइट पहले से ही बंद है) पर एआरएम के कथित लाभों को उजागर करने के लिए एक साइट शुरू की (बल्कि असफल)। RISC-V परियोजना को कई बड़ी कंपनियों का समर्थन प्राप्त है, जिसमें Google, Nvidia और Western Digital शामिल हैं।

QEMU और RISC-V टूल्स को कॉन्फ़िगर करना

हम RISC-V प्रोसेसर पर कोड तब तक नहीं चला सकते जब तक कि हम पर्यावरण की स्थापना नहीं करते। सौभाग्य से, इसके लिए भौतिक RISC-V प्रोसेसर की आवश्यकता नहीं होती है, इसके बजाय, हम qemu लेते हैं। स्थापित करने के लिए अपने ऑपरेटिंग सिस्टम के निर्देशों का पालन करें। मेरे पास MacOS है, इसलिए बस एक कमांड दर्ज करें:

# also available via MacPorts - `sudo port install qemu` brew install qemu

आसानी से, qemu कई रेडी-टू qemu-system-riscv32 -machine मशीनों के साथ आता है ( qemu-system-riscv32 -machine )।

अगला, RISC-V और RISC-V टूल के लिए OpenOCD स्थापित करें।

यहां RISC-V OpenOCD और RISC-V टूल की तैयार असेंबली डाउनलोड करें ।
हम फ़ाइलों को किसी भी निर्देशिका में निकालते हैं, मेरे पास यह है ~/usys/riscv । इसे भविष्य में उपयोग के लिए याद रखें।

 mkdir -p ~/usys/riscv cd ~/Downloads cp openocd-<date>-<platform>.tar.gz ~/usys/riscv cp riscv64-unknown-elf-gcc-<date>-<platform>.tar.gz ~/usys/riscv cd ~/usys/riscv tar -xvf openocd-<date>-<platform>.tar.gz tar -xvf riscv64-unknown-elf-gcc-<date>-<platform>.tar.gz

पर्यावरण चर RISCV_OPENOCD_PATH और RISCV_PATH सेट करें ताकि अन्य प्रोग्राम हमारी टूल श्रृंखला पा सकें। यह OS और शेल के आधार पर भिन्न दिख सकता है: मैंने पथों को ~/.zshenv जोड़ा।

 # I put these two exports directly in my ~/.zshenv file - you may have to do something else. export RISCV_OPENOCD_PATH="$HOME/usys/riscv/openocd-<date>-<version>" export RISCV_PATH="$HOME/usys/riscv/riscv64-unknown-elf-gcc-<date>-<version>" # Reload .zshenv with our new environment variables. Restarting your shell will have a similar effect. source ~/.zshenv

इस निष्पादन योग्य फ़ाइल के लिए /usr/local/bin में एक प्रतीकात्मक लिंक बनाएं ताकि आप इसे ~/usys/riscv/riscv64-unknown-elf-gcc-<date>-<version>/bin/riscv64-unknown-elf-gcc पूर्ण पथ को निर्दिष्ट किए बिना किसी भी समय चला सकें। ~/usys/riscv/riscv64-unknown-elf-gcc-<date>-<version>/bin/riscv64-unknown-elf-gcc ।

 # Symbolically link our gcc executable into /usr/local/bin. Repeat this process for any other executables you want to quickly access. ln -s ~/usys/riscv/riscv64-unknown-elf-gcc-8.2.0-<date>-<version>/bin/riscv64-unknown-elf-gcc /usr/local/bin

और वोइला, हमारे पास एक काम करने वाला RISC-V टूलकिट है! हमारे सभी निष्पादक, जैसे कि riscv64-unknown-elf-gcc , riscv64-unknown-elf-gdb , riscv64-unknown-elf-ld और अन्य, ~/usys/riscv/riscv64-unknown-elf-gcc-<date>-<version>/bin/ ।

हाय RISC- वी!

26 मई, 2019 पैच:

दुर्भाग्य से, RISC-V QEMU में एक बग के कारण, QEMU में स्वतंत्रता-ए-एसडीके 'हैलो वर्ल्ड' कार्यक्रम अब काम नहीं करता है। इस समस्या को हल करने के लिए एक पैच जारी किया गया है, लेकिन अभी के लिए, इस अनुभाग को छोड़ दें। लेख के बाद के खंडों में इस कार्यक्रम की आवश्यकता नहीं होगी। मैं स्थिति को ट्रैक करता हूं और बग को ठीक करने के बाद लेख को अपडेट करता हूं।

अधिक जानकारी के लिए यह टिप्पणी देखें।

सेट अप टूल के साथ, चलो सरल RISC-V प्रोग्राम चलाते हैं। आइए SiFive स्वतंत्रता-ए-sdk रिपॉजिटरी को क्लोन करके शुरू करें:

 cd ~/wherever/you/want/to/clone/this git clone --recursive https://github.com/sifive/freedom-e-sdk.git cd freedom-e-sdk

परंपरा से , आइए freedom-e-sdk भंडार से 'हैलो, दुनिया' कार्यक्रम शुरू करें। हम तैयार किए गए Makefile उपयोग करते हैं जो वे इस कार्यक्रम को डिबग मोड में संकलित करने के लिए प्रदान करते हैं:

 make PROGRAM=hello TARGET=sifive-hifive1 CONFIGURATION=debug software

और QEMU में चलाएं:

 qemu-system-riscv32 -nographic -machine sifive_e -kernel software/hello/debug/hello.elf Hello, World!

यह एक शानदार शुरुआत है। आप freedom-e-sdk से अन्य उदाहरण चला सकते हैं। उसके बाद, हम लिखेंगे और सी में अपने स्वयं के कार्यक्रम को डिबग करने का प्रयास करेंगे।

भोला दृष्टिकोण

आइए एक सरल प्रोग्राम से शुरू करें जो असीम रूप से दो नंबर जोड़ता है।

 cat add.c int main() { int a = 4; int b = 12; while (1) { int c = a + b; } return 0; }

हम इस कार्यक्रम को चलाना चाहते हैं, और सबसे पहले हमें RISC-V प्रोसेसर के लिए इसे संकलित करना होगा।

 # -O0 to disable all optimizations. Without this, GCC might optimize # away our infinite addition since the result 'c' is never used. # -g to tell GCC to preserve debug info in our executable. riscv64-unknown-elf-gcc add.c -O0 -g

यह a.out फ़ाइल बनाता है, जो निष्पादन योग्य फ़ाइलों के लिए चूक करती है। अब इस फ़ाइल को qemu में चलाएं:

 # -machine tells QEMU which among our list of available machines we want to # run our executable against. Run qemu-system-riscv64 -machine help to list # all available machines. # -m is the amount of memory to allocate to our virtual machine. # -gdb tcp::1234 tells QEMU to also start a GDB server on localhost:1234 where # TCP is the means of communication. # -kernel tells QEMU what we're looking to run, even if our executable isn't # exactly a "kernel". qemu-system-riscv64 -machine virt -m 128M -gdb tcp::1234 -kernel a.out

हमने riscv-qemu मशीन को चुना जो कि मूल रूप से riscv-qemu के riscv-qemu आई riscv-qemu ।

अब जब हमारा प्रोग्राम QEMU के अंदर GDB सर्वर पर localhost:1234 पर चलता है, तो हम इसे RISC-V GDB क्लाइंट से एक अलग टर्मिनल से जोड़ते हैं:

 # --tui gives us a (t)extual (ui) for our GDB session. # While we can start GDB without any arguments, specifying 'a.out' tells GDB # to load debug symbols from that file for the newly created session. riscv64-unknown-elf-gdb --tui a.out

और हम GDB के अंदर हैं!

  इस GDB को "--host = x86_64-apple-darwin17.7.0 --target = riscv64-Unknown-elf" के रूप में कॉन्फ़िगर किया गया था।  │
 कॉन्फ़िगरेशन विवरण के लिए "कॉन्फ़िगरेशन दिखाएं" टाइप करें।  │
 बग रिपोर्टिंग निर्देशों के लिए, कृपया देखें: please
 <Http://www.gnu.org/software/gdb/bugs/>।  │
 ऑनलाइन पर GDB मैनुअल और अन्य दस्तावेज़ीकरण संसाधन खोजें: and
     <Http://www.gnu.org/software/gdb/documentation/>।  │
                                                                                                       │
 सहायता के लिए, "सहायता" टाइप करें।  │
 "शब्द" से संबंधित आदेशों को खोजने के लिए "एप्रोपोस शब्द" टाइप करें ... word
 A.out से प्रतीकों को पढ़ना ... out
 (GDB)

हम GDB में। निष्पादन योग्य फ़ाइल के लिए run या कमांड start करने का प्रयास कर सकते हैं, लेकिन फिलहाल यह एक स्पष्ट कारण के लिए काम नहीं करेगा। हमने कार्यक्रम को riscv64-unknown-elf-gcc रूप में संकलित किया, इसलिए मेजबान को riscv64 वास्तुकला पर riscv64 चाहिए।

लेकिन एक रास्ता है! यह स्थिति GDB के क्लाइंट-सर्वर मॉडल के अस्तित्व का एक मुख्य कारण है। हम riscv64-unknown-elf-gdb निष्पादन योग्य फ़ाइल ले सकते हैं और इसे होस्ट पर लॉन्च करने के बजाय इसे कुछ दूरस्थ लक्ष्य (GDB सर्वर) निर्दिष्ट करें। जैसा कि आप याद करते हैं, हमने बस riscv-qemu शुरू किया और हमें localhost:1234 पर GDB सर्वर शुरू करने के लिए कहा। बस इस सर्वर से कनेक्ट करें:

  (gdb) लक्ष्य दूरस्थ: 1234 target
 रिमोट डिबगिंग का उपयोग कर: 1234

अब आप कुछ ब्रेकप्वाइंट सेट कर सकते हैं:

 (gdb) b main Breakpoint 1 at 0x1018e: file add.c, line 2. (gdb) b 5 # this is the line within the forever-while loop. int c = a + b; Breakpoint 2 at 0x1019a: file add.c, line 5.

और अंत में, निर्दिष्ट करें कि GDB continue (संक्षिप्त कमांड c ) जब तक हम ब्रेकपॉइंट तक नहीं पहुंचते:

 (gdb) c Continuing.

आप जल्दी से नोटिस करेंगे कि प्रक्रिया किसी भी तरह से समाप्त नहीं होती है। यह अजीब है ... क्या हमें तुरंत ब्रेकपाइंट b 5 तक नहीं पहुंचना चाहिए? क्या हुआ?

यहाँ आप कई समस्याएं देख सकते हैं:

पाठ UI स्रोत नहीं ढूँढ सकता। इंटरफ़ेस को हमारे कोड और पास के किसी भी ब्रेकप्वाइंट को प्रदर्शित करना चाहिए।
GDB निष्पादन की वर्तमान पंक्ति ( L?? ) को नहीं देखता है और काउंटर 0x0 ( PC: 0x0 ) प्रदर्शित करता है।
इनपुट लाइन में कुछ पाठ, जो अपनी संपूर्णता में इस तरह दिखता है: 0x0000000000000000 in ?? () 0x0000000000000000 in ?? ()

इस तथ्य के साथ कि हम ब्रेकपॉइंट तक नहीं पहुंच सकते, ये संकेतक संकेत देते हैं: हमने कुछ गलत किया। लेकिन क्या?

पर्दा उठाना -व

यह समझने के लिए कि क्या हो रहा है, आपको एक कदम वापस लेने की जरूरत है और इस बारे में बात करनी चाहिए कि वास्तव में हुड के तहत हमारा सरल सी प्रोग्राम कैसे काम करता है। main कार्य एक सरल जोड़ करता है, लेकिन यह वास्तव में क्या है? इसे main क्यों कहा जाना चाहिए, न कि origin या begin ? सम्मेलन के अनुसार, सभी निष्पादन योग्य फ़ाइलों को main कार्य के साथ निष्पादित किया जाना शुरू होता है, लेकिन क्या जादू इस व्यवहार को प्रदान करता है?

इन सवालों के जवाब के लिए, आइए अपनी जीसीसी टीम को -v ध्वज के साथ दोहराएं जो वास्तव में हो रहा है, का अधिक विस्तृत आउटपुट प्राप्त करने के लिए।

 riscv64-unknown-elf-gcc add.c -O0 -g -v

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

  # वास्तविक `gcc -v` कमांड पूर्ण पथ को आउटपुट करता है, लेकिन वे काफी हैं
 # लंबा है, इसलिए इन चर का अस्तित्व मौजूद है।
 # $ RV_GCC_BIN_PATH = / उपयोगकर्ता / twilcock / usys / riscv / riscv64-Unknown-elf-gcc- <date> - <version> / bin /
 # $ RV_GCC_LIB_PATH = $ RV_GCC_BIN_PATH /../ lib / gcc / riscv64-Unknown-elf / 8.2.0

 $ RV_GCC_BIN_PATH /../ libexec / gcc / riscv64-Unknown-elf / 8.2.0 / collect2 \
   ... काट दिया गया ... 
   $ RV_GCC_LIB_PATH /../../../// riscv64-Unknown-elf / lib / rv64imafdc / lp64d / crt0.o \ 
   $ RV_GCC_LIB_PATH / riscv64-Unknown-elf / 8.2.0 / rv64imafdc / lp64d / crtbegin.o \
   -lgcc --start-group -lc -lgloss --end-group -lgcc \ 
   $ RV_GCC_LIB_PATH / rv64imafdc / lp64d / crtend.o
   ... काट दिया गया ...
 COLLECT_GCC_OPTIONS = '- O0' '-g' '-v' '-march = rv64imafdc' '-mabi = lp64d'

मैं समझता हूं कि संक्षिप्त रूप में भी यह बहुत कुछ है, इसलिए मुझे समझाना चाहिए। पहली पंक्ति में, gcc collect2 प्रोग्राम चलाता है, crt0.o , crtbegin.o और crtend.o , -lgcc और --start-group झंडे तर्कों को पास करता है। कलेक्ट 2 का वर्णन यहां पाया जा सकता है : संक्षेप में, संग्रहण 2 स्टार्टअप पर विभिन्न आरंभीकरण कार्यों का आयोजन करता है, जिससे लेआउट एक या अधिक पास में हो जाता है।

इस प्रकार, जीसीसी हमारे कोड के साथ कई crt फ़ाइलों को संकलित करता है। जैसा कि आप अनुमान लगा सकते हैं, crt अर्थ है 'C क्रम'। यहाँ यह विस्तार से वर्णन किया गया है कि प्रत्येक crt क्या उद्देश्य है, लेकिन हम crt0 में रुचि रखते हैं, जो एक महत्वपूर्ण बात करता है:

"इस crt0] ऑब्जेक्ट में _start वर्ण शामिल होने की उम्मीद है, जो प्रोग्राम के बूटस्ट्रैप को इंगित करता है।"

"बूटस्ट्रैप" का सार मंच पर निर्भर है, लेकिन इसमें आमतौर पर महत्वपूर्ण कार्य शामिल होते हैं जैसे स्टैक फ्रेम स्थापित करना, कमांड लाइन तर्क पास करना और main कॉल करना। हां, हमें आखिरकार इस सवाल का जवाब मिल गया: यह _start हमारे मुख्य कार्य को कहता है!

हमारे ढेर को खोजें

हमने एक पहेली को हल किया, लेकिन यह हमें मूल लक्ष्य के करीब कैसे लाता है - gdb में एक सरल सी प्रोग्राम चलाने के लिए? यह कई समस्याओं को हल करने के लिए बनी हुई है: उनमें से पहली यह संबंधित है कि crt0 हमारे स्टैक को कैसे कॉन्फ़िगर करता है।

जैसा कि हमने ऊपर देखा, crt0 लिए gcc चूक। डिफ़ॉल्ट मापदंडों को कई कारकों के आधार पर चुना जाता है:

machine-vendor-operatingsystem की संरचना से संबंधित लक्ष्य ट्रिपल । हमारे पास यह riscv64-unknown-elf
लक्ष्य वास्तुकला, rv64imafdc
लक्ष्य ABI, lp64d

आमतौर पर सब कुछ ठीक काम करता है, लेकिन हर RISC-V प्रोसेसर के लिए नहीं। जैसा कि पहले उल्लेख किया गया है, crt0 के कार्यों में से एक स्टैक को कॉन्फ़िगर करना है। लेकिन वह यह नहीं जानता कि हमारे सीपीयू ( -machine ) के लिए स्टैक कहां होना चाहिए? वह हमारी मदद के बिना ऐसा नहीं कर सकता।

qemu-system-riscv64 -machine virt -m 128M -gdb tcp::1234 -kernel a.out हमने qemu-system-riscv64 -machine virt -m 128M -gdb tcp::1234 -kernel a.out मशीन का उपयोग किया। सौभाग्य से, qemu मशीन की जानकारी को dtb डंप (डिवाइस ट्री ब्लॉब) में डंप करना आसान बनाता है।

 # Go to the ~/usys/riscv folder we created before and create a new dir # for our machine information. cd ~/usys/riscv && mkdir machines cd machines # Use qemu to dump info about the 'virt' machine in dtb (device tree blob) # format. # The data in this file represents hardware components of a given # machine / device / board. qemu-system-riscv64 -machine virt -machine dumpdtb=riscv64-virt.dtb

Dtb डेटा को पढ़ना मुश्किल है क्योंकि यह मूल रूप से एक द्विआधारी प्रारूप है, लेकिन एक dtc कमांड-लाइन उपयोगिता (डिवाइस ट्री कंपाइलर) है जो फ़ाइल को कुछ और पठनीय में बदल सकती है।

 # I'm running MacOS, so I use Homebrew to install this. If you're # running another OS you may need to do something else. brew install dtc # Convert our .dtb into a human-readable .dts (device tree source) file. dtc -I dtb -O dts -o riscv64-virt.dts riscv64-virt.dtb

आउटपुट फ़ाइल riscv64-virt.dts , जहां हम riscv64-virt.dts बारे में बहुत सारी रोचक जानकारी देखते हैं: प्रोसेसर कोर की संख्या उपलब्ध है, विभिन्न परिधीय उपकरणों की मेमोरी लोकेशन, जैसे UART, आंतरिक मेमोरी (RAM) का स्थान। स्टैक इस मेमोरी में होना चाहिए, इसलिए इसे grep साथ देखें:

 grep memory riscv64-virt.dts -A 3 memory@80000000 { device_type = "memory"; reg = <0x00 0x80000000 0x00 0x8000000>; };

जैसा कि आप देख सकते हैं, इस नोड में device_type रूप में निर्दिष्ट 'मेमोरी' है। जाहिर है, हमने वह पाया जो हम ढूंढ रहे थे। reg = <...> ; अंदर मूल्यों द्वारा reg = <...> ; आप यह निर्धारित कर सकते हैं कि मेमोरी बैंक कहां से शुरू होता है और इसकी लंबाई क्या है।

Devicetree विनिर्देशन में, हम देखते हैं कि reg सिंटैक्स जोड़े की एक मनमानी संख्या है (base_address, length) । हालाँकि, reg अंदर चार अर्थ हैं। अजीब, क्या एक मेमोरी बैंक के लिए दो मूल्य पर्याप्त नहीं हैं?

फिर से, devicetree विनिर्देशन ( reg संपत्ति के लिए खोज) से हमें पता चलता है कि पते और लंबाई को निर्दिष्ट करने के लिए <u32> कोशिकाओं की संख्या माता #size-cells पिता नोड (या नोड में) में #address-cells और #size-cells गुणों द्वारा निर्धारित की जाती है। ये मान हमारी मेमोरी नोड में निर्दिष्ट नहीं हैं, और मूल मेमोरी नोड केवल फ़ाइल की जड़ है। आइए इन मूल्यों के लिए इसे देखें:

 head -n8 riscv64-virt.dts /dts-v1/; / { #address-cells = <0x02>; #size-cells = <0x02>; compatible = "riscv-virtio"; model = "riscv-virtio,qemu";

यह पता चला है कि पते और लंबाई दोनों को दो 32-बिट मान की आवश्यकता है। इसका मतलब है कि reg = <0x00 0x80000000 0x00 0x8000000>; हमारी मेमोरी 0x00 + 0x80000000 (0x80000000) शुरू होती है और 0x00 + 0x8000000 (0x8000000) बाइट्स पर 0x88000000 , 0x88000000 यह 0x88000000 पर समाप्त 0x88000000 , जो 128 मेगाबाइट से मेल खाती है।

व्यवस्था

qemu और dtc का उपयोग करके dtc हमने गुणात्मक वर्चुअल मशीन में RAM पते पाए। हम यह भी जानते हैं कि gcc डिफ़ॉल्ट रूप से crt0 रचना crt0 है, बिना स्टैक को कॉन्फ़िगर किए बिना जैसे हमें ज़रूरत होती है। लेकिन अंततः कार्यक्रम को चलाने और डिबग करने के लिए इस जानकारी का उपयोग कैसे करें?

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

सौभाग्य से, हम यह सवाल पूछने वाले पहले नहीं हैं, और एक अच्छा समाधान पहले से मौजूद है। GNU ld लिंकर आपको हमारे crt0 से उपलब्ध चरित्र को परिभाषित करने की अनुमति देता है । हम विभिन्न प्रोसेसर के लिए उपयुक्त __stack_top प्रतीक को परिभाषित कर सकते हैं।

खरोंच से अपनी स्वयं की लिंकर फ़ाइल लिखने के बजाय, यह डिफ़ॉल्ट स्क्रिप्ट को ld साथ लेने और अतिरिक्त वर्णों का समर्थन करने के लिए इसे थोड़ा संशोधित करने के लिए समझ में आता है। लिंकर स्क्रिप्ट क्या है? यहाँ एक अच्छा वर्णन है :

लिंकर स्क्रिप्ट का मुख्य उद्देश्य यह वर्णन करना है कि इनपुट और आउटपुट में फाइल सेक्शन कैसे मेल खाते हैं, और आउटपुट फाइल की मेमोरी के लेआउट को नियंत्रित करने के लिए।

यह जानते हुए, आइए डिफ़ॉल्ट लिंकर स्क्रिप्ट riscv64-unknown-elf-ld को एक नई फाइल में कॉपी करें:

 cd ~/usys/riscv # Make a new dir for custom linker scripts out RISC-V CPUs may require. mkdir ld && cd ld # Copy the default linker script into riscv64-virt.ld riscv64-unknown-elf-ld --verbose > riscv64-virt.ld

इस फ़ाइल में बहुत सारी रोचक जानकारी है, जितना हम इस लेख में चर्चा कर सकते हैं। --Verbose साथ विस्तृत आउटपुट में ld संस्करण, समर्थित आर्किटेक्चर और बहुत कुछ के बारे में जानकारी शामिल है। यह जानना अच्छा है, लेकिन लिंकर स्क्रिप्ट में ऐसा सिंटैक्स अस्वीकार्य है, इसलिए एक टेक्स्ट एडिटर खोलें और फ़ाइल से सबकुछ हटा दें।

  vim riscv64-virt.ld

 # ऊपर और =========== लाइन सहित सब कुछ निकालें
 GNU ld (GNU Binutils) 2.32
   समर्थित उत्सर्जन:
    elf64lriscv
    elf32lriscv
 आंतरिक लिंकर स्क्रिप्ट का उपयोग करना:
 ==================================================
 / * स्क्रिप्ट for -z combreloc: गठबंधन और रीकोक खंडों को छाँटें * /
 / * कॉपीराइट (C) 2014-2019 फ्री सॉफ्टवेयर फाउंडेशन, इंक।
    संशोधन के साथ या उसके बिना इस लिपि की नकल और वितरण,
    रॉयल्टी के बिना किसी भी माध्यम में अनुमति दी जाती है कॉपीराइट प्रदान किया गया
    नोटिस और यह नोटिस संरक्षित है।  * /
 OUTPUT_FORMAT ("elf64-littleriscv", "elf64-littlervv",
	       "Elf64-littleriscv")
 ... बाकी लिंकर स्क्रिप्ट ...

उसके बाद, __stack_top कमांड को मैन्युअल रूप से यह निर्धारित करने के लिए __stack_top कि कहां __stack_top होगा। OUTPUT_ARCH(riscv) शुरू होने वाली लाइन का पता लगाएँ, यह फ़ाइल के शीर्ष पर होना चाहिए, और इसके नीचे MEMORY कमांड जोड़ें:

 OUTPUT_ARCH(riscv) /* >>> Our addition. <<< */ MEMORY { /* qemu-system-risc64 virt machine */ RAM (rwx) : ORIGIN = 0x80000000, LENGTH = 128M } /* >>> End of our addition. <<< */ ENTRY(_start)

हमने RAM नामक एक मेमोरी ब्लॉक बनाया, जिसके लिए पढ़ना ( r ), लेखन ( w ), और निष्पादन योग्य कोड ( x ) को स्टोर करने की अनुमति है।

महान, हमने एक मेमोरी लेआउट को परिभाषित किया है जो हमारे virt RISC-V मशीन के विनिर्देशों से मेल खाता है। अब आप इसका उपयोग कर सकते हैं। हम अपने ढेर को स्मृति में रखना चाहते हैं।

आपको __stack_top चरित्र को परिभाषित करने की आवश्यकता है। एक पाठ संपादक में अपनी लिंकर स्क्रिप्ट ( riscv64-virt.ld ) खोलें और कुछ पंक्तियाँ जोड़ें:

 SECTIONS { /* Read-only sections, merged into text segment: */ PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x10000)); . = SEGMENT_START("text-segment", 0x10000) + SIZEOF_HEADERS; /* >>> Our addition. <<< */ PROVIDE(__stack_top = ORIGIN(RAM) + LENGTH(RAM)); /* >>> End of our addition. <<< */ .interp : { *(.interp) } .note.gnu.build-id : { *(.note.gnu.build-id) }

जैसा कि आप देख सकते हैं, हम __stack_top कमांड का उपयोग करके __stack_top को परिभाषित करते हैं। प्रतीक इस स्क्रिप्ट से जुड़े किसी भी कार्यक्रम से सुलभ होगा (यह मानते हुए कि कार्यक्रम स्वयं __stack_top नाम के साथ कुछ निर्धारित नहीं करेगा)। ORIGIN(RAM) __stack_top सेट करें। हम जानते हैं कि यह मान 0x80000000 प्लस LENGTH(RAM) , जो 128 मेगाबाइट ( 0x8000000 बाइट्स) है। इसका मतलब है कि हमारा __stack_top सेट है।

संक्षिप्तता के लिए, मैं पूरी लिंकर फ़ाइल को यहाँ सूचीबद्ध नहीं करूँगा; आप इसे यहाँ देख सकते हैं ।

इसे रोको! Hammertime! रनटाइम!

अब हमारे पास अपना C रनटाइम बनाने के लिए आवश्यक सब कुछ है। वास्तव में, यह एक काफी सरल कार्य है, यहाँ पूरी crt0.s फ़ाइल है:

 .section .init, "ax" .global _start _start: .cfi_startproc .cfi_undefined ra .option push .option norelax la gp, __global_pointer$ .option pop la sp, __stack_top add s0, sp, zero jal zero, main .cfi_endproc .end

तुरंत बड़ी संख्या में लाइनें आकर्षित करती हैं जो एक अवधि से शुरू होती हैं। यह असेंबलर के लिए एक फ़ाइल है। डॉट्स वाली पंक्तियों को कोडांतरक निर्देश कहा जाता है: वे कोडांतरक के लिए जानकारी प्रदान करते हैं। यह निष्पादन योग्य कोड नहीं है, जैसे RISC-V कोडांतरक निर्देश जैसे jal और add ।

फाइल लाइन से लाइन के माध्यम से चलते हैं। हम विभिन्न मानक RISC-V रजिस्टरों के साथ काम करेंगे, इसलिए इस तालिका को देखें , जिसमें सभी रजिस्टर और उनके उद्देश्य शामिल हैं।

 .section .init, "ax"

जैसा कि GNU असेंबलर में 'मैनुअल' में कहा गया है , यह लाइन असेंबलर को निम्न कोड को .init सेक्शन में डालने के लिए .init , जिसे आवंटित किया गया है ( a ) और एक्जीक्यूटेबल ( x )। यह खंड ऑपरेटिंग सिस्टम के भीतर कोड चलाने के लिए एक और आम सम्मेलन है। हम एक ओएस के बिना शुद्ध हार्डवेयर पर काम करते हैं, इसलिए हमारे मामले में ऐसा निर्देश बिल्कुल आवश्यक नहीं हो सकता है, लेकिन किसी भी मामले में यह अच्छा अभ्यास है।

 .global _start _start:

.global ld को निम्न वर्ण उपलब्ध कराता है। इसके बिना, लिंक काम नहीं करेगा, क्योंकि लिंकर स्क्रिप्ट में ENTRY(_start) _start प्रतीक को निष्पादन योग्य फ़ाइल के प्रवेश बिंदु के रूप में इंगित करता है। अगली पंक्ति असेंबलर को बताती है कि हम _start वर्ण की परिभाषा शुरू कर रहे हैं।

 _start: .cfi_startproc .cfi_undefined ra ...other stuff... .cfi_endproc

ये .cfi निर्देश आपको फ्रेम की संरचना और इसे संभालने के तरीके के बारे में सूचित करते हैं। .cfi_startproc और .cfi_endproc फ़ंक्शन के आरंभ और अंत का संकेत देते हैं, और .cfi_undefined ra कोडांतरक को _start होने से पहले _start गए कोड को किसी भी मान में पुनर्स्थापित नहीं करना चाहिए ।

 .option push .option norelax la gp, __global_pointer$ .option pop

जब आप विकल्पों के एक विशिष्ट सेट को लागू करने की आवश्यकता होती है तो ये .option निर्देश कोड के अनुसार कोडांतरक के व्यवहार को बदलते हैं। यहाँ इस बात का विस्तृत विवरण दिया गया है कि इस सेगमेंट में .option का उपयोग क्यों महत्वपूर्ण है:

... चूंकि हम संभवतः GP के सापेक्ष छोटे अनुक्रमों के अनुक्रम को संबोधित करते हैं, इसलिए GP का प्रारंभिक लोडिंग कमजोर नहीं होना चाहिए और ऐसा कुछ होना चाहिए:
 .option push .option norelax la gp, __global_pointer$ .option pop 
ताकि विश्राम के बाद आपको निम्नलिखित कोड मिलें:
 auipc gp, %pcrel_hi(__global_pointer$) addi gp, gp, %pcrel_lo(__global_pointer$) 
सरल के बजाय:
 addi gp, gp, 0 

और अब हमारे crt0.s का अंतिम भाग:

 _start: ...other stuff... la sp, __stack_top add s0, sp, zero jal zero, main .cfi_endproc .end

यहां हम अंततः __stack_top प्रतीक का उपयोग कर सकते हैं, जिसे हमने बनाने में बहुत मेहनत की थी। छद्म-निर्देश la (लोड पता) __stack_top मान को sp रजिस्टर (स्टैक पॉइंटर) में लोड करता है, इसे बाकी प्रोग्राम में उपयोग के लिए सेट करता है।

फिर add s0, sp, zero रजिस्टरों के मानों को sp और add s0, sp, zero जोड़ता zero (जो कि वास्तव में 0 के कठिन संदर्भ के साथ एक रजिस्टर x0 ) और परिणाम को रजिस्टर s0 में डालता है। यह एक विशेष रजिस्टर है जो कई मामलों में असामान्य है। सबसे पहले, यह एक "लगातार रजिस्टर" है, अर्थात, फ़ंक्शन कॉल करने पर इसे सहेजा जाता है। दूसरे, s0 कभी-कभी एक फ्रेम पॉइंटर के रूप में कार्य करता है, जो प्रत्येक फ़ंक्शन को इस फ़ंक्शन को दिए गए मापदंडों को संग्रहीत करने के लिए स्टैक में एक छोटी सी जगह देता है। स्टैक और फ्रेम पॉइंटर्स के साथ फ़ंक्शन कॉल कैसे काम करते हैं यह एक बहुत ही दिलचस्प विषय है जिसे आप आसानी से एक अलग लेख के लिए समर्पित कर सकते हैं, लेकिन अभी के लिए, बस यह जान लें कि हमारे रनटाइम में फ्रेम पॉइंटर s0 को इनिशियलाइज़ करना महत्वपूर्ण है।

आगे हम jal zero, main कथन देखते हैं। यहां jal मतलब है जंप और लिंक। निर्देश की उम्मीद है कि jal rd (destination register), offset_address । कार्यात्मक रूप से, jal rd को अगले निर्देश ( pc रजिस्टर प्लस चार) का मान लिखता है, और फिर pc रजिस्टर को वर्तमान pc मूल्य और साइन एक्सटेंशन के साथ ऑफसेट पते को प्रभावी रूप से "कॉलिंग" इस पते पर सेट करता है।

जैसा कि ऊपर उल्लेख किया गया है, x0 कसकर शाब्दिक मान 0 से बंधा हुआ है, और इसे लिखना बेकार है। , zero , RISC-V x0 . offset_address . , ?

jal zero, offset_address . , , . ISA, . , jal unconditional jump , RISC-V jal , jal zero, main .

आरआईएससी-वी में कई ऐसी अनुकूलनियां हैं, जिनमें से अधिकांश तथाकथित छद्म - निर्देशों का रूप लेती हैं । असेंबलर्स जानते हैं कि उन्हें वास्तविक हार्डवेयर निर्देशों में कैसे अनुवाद करना है। उदाहरण के लिए, j offset_addressRISC-V असेंबलर्स छद्म- अनियंत्रित कूद के निर्देश का अनुवाद करते हैं jal zero, offset_address। आधिकारिक तौर पर समर्थित छद्म निर्देशों की पूरी सूची के लिए , RISC-V विनिर्देश (संस्करण 2.2) देखें ।

 _start: ...other stuff... jal zero, main .cfi_endproc .end

हमारी अंतिम पंक्ति कोडांतरक निर्देश है .end, जो केवल फ़ाइल के अंत को चिह्नित करता है।

डीबग करें लेकिन अब असली के लिए

आरआईएससी-वी प्रोसेसर पर एक साधारण सी प्रोग्राम को डिबग करने की कोशिश करते हुए, हमने बहुत सारी समस्याओं को हल किया। सबसे पहले, RISC-V वर्चुअल मशीन में हमारी मेमोरी का उपयोग qemuऔर dtcपाया गया virt। फिर हमने इस जानकारी का उपयोग लिंकर की डिफ़ॉल्ट स्क्रिप्ट के हमारे संस्करण में मेमोरी आवंटन को मैन्युअल रूप से नियंत्रित करने के लिए किया riscv64-unknown-elf-ld, जिसने हमें प्रतीक को सही ढंग से निर्धारित करने की अनुमति दी __stack_top। तब हमने इस प्रतीक का उपयोग अपने स्वयं के संस्करण में किया crt0.s, जो हमारे स्टैक और ग्लोबल पॉइंटर्स को सेट करता है, और अंत में फ़ंक्शन को कहा जाता है main। अब आप अपने लक्ष्य को प्राप्त कर सकते हैं और GDB में हमारे सरल प्रोग्राम को डिबग करना शुरू कर सकते हैं।

यहाँ स्मरण करो सी कार्यक्रम ही है:

 cat add.c int main() { int a = 4; int b = 12; while (1) { int c = a + b; } return 0; }

संकलन और लिंकिंग:

 riscv64-unknown-elf-gcc -g -ffreestanding -O0 -Wl,--gc-sections -nostartfiles -nostdlib -nodefaultlibs -Wl,-T,riscv64-virt.ld crt0.s add.c

यहां हमने पिछली बार की तुलना में बहुत अधिक झंडे का संकेत दिया, तो चलिए उन लोगों के माध्यम से चलते हैं जिन्हें हमने पहले नहीं बताया है।

-ffreestanding संकलक को बताता है कि मानक पुस्तकालय मौजूद नहीं हो सकता है , इसलिए इसकी अनिवार्य उपस्थिति के बारे में धारणा बनाने की आवश्यकता नहीं है। अपने होस्ट (ऑपरेटिंग सिस्टम) पर एप्लिकेशन शुरू करते समय इस पैरामीटर की आवश्यकता नहीं होती है, लेकिन इस मामले में यह नहीं है, इसलिए इस जानकारी के संकलक को सूचित करना महत्वपूर्ण है।

-Wl- लिंकर ( ld) को पास करने के लिए झंडे की एक अल्पविराम से अलग सूची । यहां, इसका --gc-sectionsअर्थ है "कचरा संग्रह अनुभाग", और ldलिंक करने के बाद अप्रयुक्त अनुभागों को हटाने का निर्देश दिया गया है। झंडे -nostartfiles, -nostdlibऔर -nodefaultlibsमानक प्रणाली स्टार्टअप फ़ाइलों (उदाहरण के लिए, डिफ़ॉल्ट) को संसाधित नहीं करने के लिए लिंकर को बताएंcrt0), सिस्टम stdlib के मानक कार्यान्वयन और मानक सिस्टम डिफ़ॉल्ट लिंक्ड लाइब्रेरी। हमारे पास अपनी स्क्रिप्ट crt0और लिंकर है, इसलिए इन झंडों को पास करना महत्वपूर्ण है ताकि डिफ़ॉल्ट मान हमारी उपयोगकर्ता प्राथमिकताओं के साथ संघर्ष न करें।

-Tहमारे लिंकर स्क्रिप्ट के लिए पथ को इंगित करता है, जो हमारे मामले में सरल है riscv64-virt.ld। अंत में, हम उन फ़ाइलों को निर्दिष्ट करते हैं जिन्हें हम संकलित करना, संकलित करना और रचना करना चाहते हैं: crt0.sऔर add.c। पहले की तरह, परिणाम एक पूर्ण और तैयार फ़ाइल चलाने के लिए कहा जाता है a.out।

अब हमारे सुंदर नए ब्रांड को नया निष्पादन योग्य चलाएं qemu:

 # -S freezes execution of our executable (-kernel) until we explicitly tell # it to start with a 'continue' or 'c' from our gdb client qemu-system-riscv64 -machine virt -m 128M -gdb tcp::1234 -S -kernel a.out

अब gdb, a.outअंतिम तर्क के साथ इसे निर्दिष्ट करने के लिए डिबगिंग प्रतीकों को लोड करना याद रखें :

 riscv64-unknown-elf-gdb --tui a.out GNU gdb (GDB) 8.2.90.20190228-git Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-apple-darwin17.7.0 --target=riscv64-unknown-elf". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from a.out... (gdb)

gdb gdb , qemu :

 (gdb) target remote :1234 │ Remote debugging using :1234

main:

 (gdb) b main Breakpoint 1 at 0x8000001e: file add.c, line 2.

 (gdb) c Continuing. Breakpoint 1, main () at add.c:2

, 2! , - L , PC: L2 , PC: — 0x8000001e . , :

gdb : -s , info all-registers . . … , , !

आगे क्या है?

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

पढ़ने के लिए धन्यवाद! मुझे अगले लेख में मिलने की उम्मीद है!

इसके साथ ही

यदि आप लेख पसंद करते हैं और अधिक जानना चाहते हैं, तो CppCon2018 सम्मेलन से मैट बीबोल्ट की प्रस्तुति "बिट्स बिट्स: हाउ वी वी गेट इन (मुख्य)" शीर्षक से देखें। वह विषय की तुलना में हम यहाँ हैं थोड़ा अलग तरीके से। वास्तव में अच्छा व्याख्यान, अपने लिए देखें!

खरोंच से आरआईएससी-वी