- कॉलेज के दिनों की एक परियोजना में, खुद डिज़ाइन किए गए RISC ISA-आधारित CPU और स्वनिर्मित C compiler का उपयोग करके Xv6 operating system को port करने का अनुभव साझा किया गया है
- परियोजना को CPU डिज़ाइन, C compiler (Ucc) विकास, और Xv6 porting सहित हर घटक को स्वयं बनाने के तरीके से आगे बढ़ाया गया
- टीम ने OS चलाने के लिए interrupts, virtual memory, cache जैसी मुख्य hardware-software सुविधाओं के डिज़ाइन की चुनौती ली
- Xv6 porting के दौरान portability समस्याएँ, debugging की कठिनाइयाँ, cache bugs जैसी कई चुनौतियों का सामना हुआ, लेकिन उन्हें खुद हल किया गया
- SL, Minesweeper, 2048 जैसे interactive applications और ray-tracing program तक सफलतापूर्वक चलाए गए, जिससे शैक्षणिक और तकनीकी दोनों स्तरों पर बड़ी उपलब्धि मिली
परियोजना का अवलोकन
- यह परियोजना Tokyo University के Department of Information Science की एक प्रमुख प्रयोगात्मक assignment है, जिसका फोकस छात्रों को central processing unit (CPU), hardware design, compiler निर्माण, और application execution का व्यावहारिक अनुभव देना है
- परियोजना का लक्ष्य खुद डिज़ाइन किए गए CPU की ISA को FPGA पर सीधे implement करना, उसके लिए C toolchain (Ucc) बनाना, और उसे XO6 जैसे operating system porting तक विस्तारित करना था
- प्रयोग की अधिकांश प्रक्रिया self-directed learning के रूप में चली
CPU प्रयोग और असाइनमेंट
- 4~5 लोगों की टीमों ने नई CPU architecture डिज़ाइन करने, उसे FPGA पर implement करने, और उस architecture के लिए compiler विकसित करने में भाग लिया
- OCaml subset compiler बनाने के बाद ray tracing program चलाना अनिवार्य मूल्यांकन बिंदु था
- अतिरिक्त समय मिलने पर अपनी अलग challenge set की जा सकती थी, और कुछ छात्रों ने CPU acceleration, multicore development, music/game execution जैसे extended experiments किए
- Group 6 टीम ने खास तौर पर operating system porting को लक्ष्य बनाया, और यहीं से नया संयुक्त दल (Group X) बना
Xv6 OS और porting की चुनौती
- porting target के रूप में MIT द्वारा शिक्षा के लिए विकसित Xv6 (Unix v6-आधारित, x86 के लिए) चुना गया
- Xv6 एक सरल Unix-आधारित OS है, लेकिन वास्तविक hardware पर चलाने के लिए C89 compiler, विशेष interrupts, virtual address support, और कम portability जैसी कई समस्याएँ मौजूद थीं
- Xv6 को C language में
char 1 byte और int 4 byte जैसी x86 विशेषताओं को मानकर बनाया गया था, इसलिए porting के समय कई समस्याएँ आईं
compiler और toolchain विकास (Ucc)
- मौजूदा प्रयोगों में OCaml compiler विकास मानक था, लेकिन Xv6 चलाने के लिए C89 compiler चाहिए था, इसलिए उसे सीधे बनाने का निर्णय लिया गया
- टीम के एक सदस्य के C compiler prototype के आधार पर नया toolchain स्वयं बनाया गया (Ucc)
- compiler के साथ-साथ Primitive Linker और debug tools भी सीधे डिज़ाइन किए गए
CPU और simulator डिज़ाइन
- hardware description language (HDL, जैसे Verilog / VHDL) से CPU circuitry डिज़ाइन करने के बाद Vivado/Quartus जैसी logic synthesis प्रक्रियाओं के जरिए उसे वास्तविक FPGA पर implement किया गया
- बार-बार की logic synthesis प्रक्रिया में बहुत समय लगता था, इसलिए व्यवहार में काफी इंतज़ार करना पड़ता था
- CPU की मूल सुविधाओं के बाद interrupts, MMU, TLB जैसी OS execution के लिए आवश्यक hardware support भी अलग से डिज़ाइन किए गए
- अंततः CPU को GAIA नाम दिया गया
- simulator में वास्तविक interrupts, virtual address translation, और debugging tools जोड़े गए
porting प्रक्रिया की समस्याएँ और समाधान
- Xv6 की कम portability के कारण CPU और compiler specification के अनुसार असामान्य behavior सामने आया
- उदाहरण:
char और int को 32-bit परिभाषित करने से pointer arithmetic और stack structure टूटने जैसी समस्याएँ
- compiler Ucc में
char को 8-bit के अनुरूप सुधार किया गया
- interrupt handling सबसे कठिन क्षेत्रों में से एक था, इसलिए अपने simulator में disassembler, state dump जैसे debugging tools जोड़े गए
- cache alias समस्या इसलिए हुई क्योंकि GAIA cache index के लिए virtual address का उपयोग करता था; इसे Page Coloring तकनीक अपनाकर हल किया गया
अंतिम परिणाम: OS और ऐप्स का execution
- 1 मार्च को आखिरकार Xv6 को simulator और वास्तविक CPU (hardware) दोनों पर पूरी तरह चलाने में सफलता मिली
- स्वयं बनाए गए mini curses, SL command, Minesweeper, 2048 जैसे interactive apps सफलतापूर्वक चले
- खास तौर पर 2048 के लिए non-canonical input support का डिज़ाइन जोड़ा गया
- Xv6 में बदलाव करके POSIX-style ioctl, termios जैसी सुविधाओं के समकक्ष support भी जोड़ा गया
- छोटा assembler, mini vi आदि भी implement किए गए, जिससे एक व्यावहारिक real-time programming environment तैयार हुआ
- ray tracing program को भी operating system के ऊपर चलाया गया, जिससे मूल प्रयोग के लक्ष्य से आगे का परिणाम हासिल हुआ
परियोजना का महत्व और बाद के उदाहरण
- इस प्रयोग के बाद कई पीढ़ियों के छात्रों ने खुद CPU और OS बनाकर अलग-अलग प्रयोग लगातार जारी रखे
- उदाहरण के लिए RISC-V ISA अपनाना, अपना OS बनाना, Linux चलाना आदि तक विस्तार हुआ
- इस अभ्यास के जरिए hardware/software पूरे stack का प्रत्यक्ष अनुभव मिला, जिससे algorithms, hardware-software integration, और low-level structures की वास्तविक समझ बढ़ी
- “wheel reinventing” को अक्षम बताने वाली आलोचना भी है, लेकिन खुद बनाकर सीखने का प्रभाव और आनंद बहुत बड़ा बताया गया
वास्तविक अनुभव और source code
- GAIA CPU + Xv6 डेमो पर इसे सीधे चलाकर देखा जा सकता है
- MIPS porting version को यहाँ open source के रूप में जारी किया गया है
निष्कर्ष
- “खुद बनाने जितना सिखाने वाला कुछ नहीं” इस सीख के साथ, hardware-software integration के अनुभव के महत्व पर ज़ोर दिया गया
- बाद की छात्र पीढ़ियाँ भी नए लक्ष्यों को चुनौती देती रहीं, और भविष्य में अपनी ISA पर Linux या VM चलने की उम्मीद व्यक्त की गई
- अंत में परियोजना में भाग लेने वाले सदस्यों के नामों के साथ लेख समाप्त होता है
4 टिप्पणियां
यूनिवर्सिटी में ऐसा अनुभव मिलना सच में ईर्ष्या करने लायक है। काफ़ी मज़ेदार लगता है..
सच में बहुत मज़ेदार रहा होगा।
थोड़ा और नीचे स्क्रॉल करें…
8-बिट CPU बनाना…?
https://eater.net/8bit
Hacker News की राय
इससे मुझे कॉलेज के दिनों का एक group project याद आ गया, जो हम तीन लोगों ने 3 हफ्तों तक किया था। कई topics में से एक था बहुत बुनियादी operating system खुद बनाना, और हमने professors से पूछा कि क्या Raspberry Pi पर MINIX3 port करना ठीक रहेगा, तो उन्होंने अनुमति दे दी (MINIX3 का BeagleBoard के लिए ARM port पहले से था, इसलिए लगा कि यह संभव होगा).<br>यह हमारी उम्मीद से कहीं ज़्यादा मुश्किल निकला, और ऐसे technical problems आने लगे जिनकी हमने कल्पना भी नहीं की थी। खासकर Raspberry Pi 3 का supervisor mode की जगह hypervisor mode में boot होना बहुत परेशान करने वाला था, और QEMU की Raspberry Pi emulation accuracy इतनी खराब थी कि OS development के लिए लगभग बेकार थी। समाधान ढूँढने के लिए हमने low-level hardware debugging में पूरा एक हफ्ता लगा दिया। <br>आखिरकार हमने UART, GPIO, और framebuffer drivers के साथ एक working port बना लिया, और उसे Raspberry Pi 2 और 3 पर सफलतापूर्वक चलाया। presentation भी असली hardware पर की, shell script से ramdisk image output किया, GPIO pins monitor करके slides आगे-पीछे करवाईं, और चाकू से pins short करके उसे सीधे नियंत्रित किया। originality के लिहाज़ से वह ज़बरदस्त presentation थी, और शायद वह SD card image अब भी मेरे पास कहीं होगी
सुनने में बहुत शानदार अनुभव लगता है<br>जिस पल आपने MINIX3 को Raspberry Pi पर port करने का प्रस्ताव रखा, हो सकता है professors ने तभी failure की उम्मीद कर ली हो<br>जब QEMU की Raspberry Pi emulation accuracy खराब होती है, तो मैं आम तौर पर यह strategy अपनाता था कि पहले QEMU में OS को चलने लायक बनाओ, फिर hardware पर थोड़ा किस्मत के भरोसे जाओ। फिर भी यह ठीक-ठाक काम कर जाता था<br>जानना चाहूँगा कि असली Raspberry Pi पर debugging आपने कैसे की
GPIO short करने के लिए चाकू इस्तेमाल करने की बात सुनकर मुझे ATX motherboard पर power switch के बिना boot करने के लिए दो power pins short करने का पुराना अनुभव याद आ गया<br>फिर भी तुम्हारा setup उससे कहीं ज़्यादा शानदार है। बढ़िया काम
SFU में मैंने 25~30 साल पहले कुछ ऐसा ही किया था। हालाँकि मैंने उस पर OS और compiler नहीं चढ़ाया था, और यह team project भी नहीं था<br>अगर ऐसे experiments में रुचि है, तो Turing Complete की सिफारिश करूँगा, क्योंकि उसमें guide और accessible tooling है। कुछ gates से शुरू करके असली computer तक बनाया जा सकता है। community और components भी share किए जा सकते हैं, और उसमें RiscV core भी है। यह सच में मज़ेदार है, इसलिए Steam पर इसे ज़रूर आज़माएँ<br>Turing Complete Steam लिंक
यह पढ़कर मुझे धुंधले तौर पर एक ऐसा ही academic(?) project याद आ रहा है। कम-से-कम उसमें custom C compiler और custom OS थे, इतना याद है। नाम ठीक-ठीक याद नहीं
पहले आया हुआ संबंधित topic देखें पिछली पोस्ट का लिंक
जब आप CPU + compiler + OS खुद बना रहे होते हैं, तो नीचे कोई platform होता ही नहीं। मैं ही platform हूँ.<br>bug ही system का नियम बन जाता है। आम तौर पर हम किसी और के बनाए abstraction layer में debug करते हैं, लेकिन यहाँ उन नियमों को भी आप खुद परिभाषित करते हैं। OP ने अपने ही बनाए नियमों को debug किया है
सच में प्रभावशाली है। low-end क्षेत्र का काम अक्सर नीरस और बहुत समय लेने वाला होता है, खासकर तब जब debugger जैसे ज़रूरी tools भी न हों
Magic-1 और BMOW ने भी पहले ऐसा ही कुछ किया था<br>विस्तार के लिए homebrewcpu.com देखें<br>खुद CPU बनाने वाली sites की सूची के लिए homebrewcpuring.org देखें
अब वक्त आ गया है कि FPGA पर implement करने के बजाय सीधे semiconductor lab में जाकर कहो कि अपना CPU खुद बनाकर दो