RISC-V: उन्हें बेहतर पता होना चाहिए था

मूल लेख ↗ Hacker News चर्चा ↗

एक खुले, royalty‑free CPU instruction set के रूप में RISC‑V के तेज़ उभार की तुलना उसकी तकनीकी डिज़ाइन पसंदों पर तीखी आलोचना से की जा रही है। टिप्पणीकार बहस करते हैं कि क्या उसकी fragmentary optional extensions, awkward instruction encodings, और कमजोर runtime feature detection उसे high‑performance या general‑purpose systems के लिए खराब आधार बनाती हैं, या फिर ये खामियाँ एक open standard और बढ़ते ecosystem के लाभों की तुलना में मामूली हैं। कई लोग निष्कर्ष निकालते हैं कि, भले ही ISA‑purist दृष्टिकोण से यह एक missed opportunity हो, RISC‑V embedded, MCU, और accelerator designs में proprietary cores को विस्थापित करने के लिए “काफी अच्छा” है, जहाँ लागत और licensing प्रमुख हैं।

समग्र भावना

  • कई लोग मानते हैं कि लेख RISC‑V की वास्तविक डिज़ाइन खामियों (optionalism, encodings, traps, interrupts) को सही तरह से उजागर करता है।
  • अन्य लोग तर्क देते हैं कि आलोचना जरूरत से ज्यादा है: RISC‑V “ठीक है”, वास्तविक उत्पादों में उपयोगी है, और हर ISA के कुछ बदसूरत कोने होते हैं।
  • कई लोग नोट करते हैं कि, Linux की तरह, “काफी अच्छा + मुफ़्त” अक्सर “तकनीकी रूप से बेहतर + लाइसेंस्ड” पर भारी पड़ सकता है।

वैकल्पिक extensions और fragmentation

  • मुख्य चिंता: लगभग सब कुछ optional है; हर option variants की संख्या दोगुनी कर देता है।
  • सभी extensions (vendor ones सहित) को enumerate करने का सरल, standard तरीका न होना portable binaries, kernels, और blobs को कठिन बनाता है।
  • कुछ लोग कहते हैं कि embedded के लिए यह समस्या नहीं है (आपको exact chip पता होता है), या OS-level apps के लिए (आप RVA23 जैसी profile को target करते हैं)।
  • अन्य लोग जवाब देते हैं कि shared libraries, blobs, और लंबे समय तक चलने वाले products इसे एक व्यावहारिक समस्या बनाते हैं, केवल सैद्धांतिक नहीं।
  • Profiles (जैसे RVA23) को आंशिक mitigation माना जाता है, लेकिन पूर्ण समाधान नहीं।

Instruction encoding, code density, और decoding

  • compressed (16/32‑bit) बनाम fixed‑width बनाम पूरी तरह variable‑length encodings पर बहस:
    • आलोचक: RISC‑V variable length की complexity cost तो देता है, लेकिन code density में केवल AArch64 के बराबर पहुँचता है, उससे स्पष्ट रूप से बेहतर नहीं; extensions के बीच overlapping encodings को खतरनाक और भ्रमित करने वाला कहा जाता है।
    • समर्थक: आधुनिक cores पहले से ही complex instructions को crack/fuse करते हैं (x86, ARM), इसलिए RISC‑V का तरीका तुलनीय है; दावा है कि RV64GC/RVA23 text size में x86‑64 से बेहतर हैं और AArch64 के साथ प्रतिस्पर्धी हैं।
  • कुछ microarchitectural details (JAL range, flags की कमी, immediate layouts) को “unforced errors” कहा जाता है; अन्य लोग कहते हैं कि ये सरल high‑performance designs के लिए उचित trade‑offs हैं।

Embedded बनाम high‑performance use cases

  • कई लोग RISC‑V को deeply embedded और MCU‑like भूमिकाओं के लिए उपयुक्त मानते हैं, खासकर 8051‑class cores और licensed ARM‑M के कानूनी रूप से “clean” विकल्प के रूप में।
  • Interrupt latency और context‑save overhead (खासकर FP के साथ) की आलोचना की जाती है; कुछ लोग नोट करते हैं कि इन्हें बेहतर conventions या extensions (जैसे Zfinx) से कम किया जा सकता है।
  • desktop/server‑class cores के लिए विचार अलग‑अलग हैं:
    • संशयवादी: RISC‑V ने ARMv8/x86 के सबक नहीं अपनाए, इसलिए यह top‑end OoO cores के लिए कमजोर फिट है; high‑margin markets बस ARM का भुगतान कर सकते हैं।
    • आशावादी: समय के साथ open cores और profiles M‑series/A‑series‑class performance तक पहुँच जाएंगे; मौजूदा high‑end x86/ARM cores पहले से ही micro‑ops के पीछे ISA quirks छिपाते हैं।

Software compatibility और feature detection

  • कड़ी आलोचना कि आप undefined instructions पर भरोसेमंद trap नहीं कर सकते क्योंकि वे किसी अन्य extension का हिस्सा हो सकते हैं; इसलिए opcodes चलाकर probing करना unsafe है।
  • कुछ लोग तर्क देते हैं कि OS‑mediated discovery (device tree, /proc/cpuinfo, standardized profiles) practical software के लिए पर्याप्त है।
  • Embedded developers नोट करते हैं कि उन्हें अक्सर parts के परिवारों का समर्थन करना पड़ता है; समान cores के बीच silent behavior changes (विशेषकर vendor blobs के साथ) को गंभीर जोखिम माना जाता है।

कानूनी, बाज़ार, और “openness” तर्क

  • एक केंद्रीय pro‑RISC‑V थीम: royalty‑free, patent‑aware design और “open standard” status आकर्षक हैं, खासकर इनके लिए:
    • लागत‑संवेदनशील embedded devices।
    • वे कंपनियाँ और देश जो ARM/x86 licensing या geopolitical leverage से बचना चाहते हैं।
  • अन्य लोग चेतावनी देते हैं कि microarchitectures और extensions पर patents अभी भी मौजूद हैं, और किसी भी ISA को पूरी तरह troll‑proof साबित नहीं किया जा सकता।

RISC‑V एक “ISA framework” के रूप में और भविष्य की दिशाएँ

  • कुछ लोग RISC‑V को एक single ISA नहीं, बल्कि कई ISAs का generator मानते हैं (base + mix‑and‑match extensions)।
  • इस flexibility की प्रशंसा accelerators (AI, GPUs, custom IP) और hobby cores के लिए की जाती है, लेकिन ecosystem fragmentation के लिए आलोचना भी होती है।
  • सुझाव सामने आते हैं:
    • एक “RISC‑VI” या एक re‑encoded, stricter profile जो ARMv8 और RISC‑V की अपनी गलतियों से सीखता हो।
    • और अधिक fine‑grained options जोड़ने के बजाय, कुछ well‑defined profiles और query mechanisms के आसपास अधिक आक्रामक standardization।