CPU में “You” डालना

 (cpu.land)
8 पॉइंट द्वारा GN⁺ 2023-07-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक व्यक्तिगत learning project की भूमिका है, जिसका उद्देश्य आखिर तक समझना है कि कंप्यूटर में कोई program चलाने पर असल में क्या होता है
  • मुख्य सवाल यह है कि क्या program सीधे CPU पर execute होता है, system call कैसे काम करता है, और कई program एक साथ कैसे चलते हैं
  • विश्वविद्यालय की कक्षाओं के बाहर व्यापक system materials मिलना मुश्किल था, इसलिए अलग-अलग quality वाले स्रोतों और टकराती जानकारी को खुद छांटना पड़ा
  • कई हफ्तों तक शोध करके और लगभग 40 पन्नों के notes बनाकर, लेखक को कंप्यूटर के start होने से लेकर program execution तक की प्रक्रिया बेहतर समझ में आई
  • लेखक कहता है कि जिन्हें लगता है कि वे यह सब पहले से जानते हैं, वे भी कुछ नया सीख सकते हैं, और अगर समय कम हो तो पहले अध्याय 3 पढ़ने की सलाह देता है

program execution को समझने की शुरुआत

  • कंप्यूटर में कोई program चलाते समय ठीक-ठीक क्या होता है, यही इस लेख की शुरुआत का बिंदु है
  • low-level ज्ञान कुछ हद तक था, लेकिन कई टुकड़ों को एक ही flow में जोड़ना मुश्किल था
  • सवाल तीन दिशाओं में आगे बढ़ता है
    • क्या program सचमुच सीधे CPU पर execute होता है
    • system call क्या है और यह वास्तव में कैसे काम करता है
    • कई program एक साथ कैसे चलते हैं

शोध प्रक्रिया और पढ़ने का क्रम

  • व्यापक system materials ज्यादा नहीं थे, इसलिए कई स्रोतों की खुद जांच करनी पड़ी, और हर सामग्री की quality और contents अलग थे
  • कई हफ्तों की जांच और लगभग 40 पन्नों के notes के जरिए, startup process से लेकर program execution तक कंप्यूटर कैसे काम करता है, यह बेहतर समझ में आया
  • लक्ष्य था वह एक ठोस explanatory article खुद लिखना, जिसे लेखक शुरू से खोजना चाहता था
  • जिन पाठकों को लगता है कि वे पहले से यह विषय जानते हैं, या जिनके पास समय कम है, उन्हें पहले अध्याय 3 पढ़ने की सलाह दी जाती है
  • अगला लेख अध्याय 1: The “Basics” से जारी रहता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-24
Hacker News राय

  • इसे बनाने वाला मैं ही हूं। पढ़ने और Hacker News की तरह ढेरों सुधार बताने के लिए धन्यवाद। Putting the "You" in CPU अभी भी काम में है, और मूल रूप से मेरा इरादा था कि इसे और पॉलिश करके, कंटेंट जोड़कर अगले हफ्ते के आसपास HN पर डालूं
    मैं 17 साल का हूं, और 1 साल पहले हाई स्कूल छोड़कर Hack Club(https://hackclub.com/) में फुल-टाइम काम करना शुरू किया। जब से याद है, तब से प्रोग्रामिंग करता आया हूं, और करीब 6 साल पहले प्रोग्रामिंग और अपनी दूसरी रुचियों पर ज्यादा ध्यान देने के लिए होमस्कूलिंग शुरू की
    सब कुछ खुद से सीखा है, इसलिए मैंने यूनिवर्सिटी का systems course कभी नहीं लिया, और “जब कुछ चलाते हैं तो क्या होता है” इस सवाल पर अपना जवाब मुझे संतोषजनक नहीं लगता था। इसलिए मैंने बहुत समय लगाकर जितनी गहराई तक हो सके सीखा, और इस दौरान समझ आया कि operating systems और hardware सीखना वाकई मजेदार है, लेकिन इस विषय पर online resources अक्सर बहुत खराब होते हैं
    रिसर्च करते हुए अक्सर 2014 के lecture slides PDF या StackOverflow के ऐसे जवाब मिलते थे जो असल में गलत होते थे या जरूरत से ज्यादा सरल बना दिए गए होते थे। इसलिए इस क्षेत्र को खुद से सीखने वालों के लिए बेहतर resource बनने की उम्मीद से मैंने Putting the "You" in CPU लिखा। अभी SMP पर कुछ और पैराग्राफ लिखने बाकी हैं, इसलिए यह परफेक्ट नहीं है, लेकिन मुझे लगता है कि मैंने जो ज्यादातर resources देखे हैं, उनसे यह काफी बेहतर है। diagrams और schematics भी पहली बार बनाए, और बाद के chapters में वे बेहतर होते गए; आखिर के कुछ diagrams पर मुझे काफी गर्व है
    पूरा GitHub पर open source में उपलब्ध है: https://github.com/hackclub/putting-the-you-in-cpu

    • आजकल मैं भी अक्सर सोचता हूं कि “ऐसे online resources बहुत खराब हैं।” खासकर जब Linux kernel के detailed block diagrams, page table कैसे काम करती है, platform-specific function calling ABI comparisons, low-level network protocol details, reserved Linux PID numbers जैसी चीजें ढूंढता हूं
      कभी-कभी Reddit threads में जवाब मिल जाते हैं, लेकिन आम तौर पर उनमें noise मिला होता है, और यह भी संदेह रहता है कि ज्ञान को संरक्षित करने के लिए Reddit भरोसेमंद जगह है या नहीं। StackOverflow खास task हल करने वाले सवालों पर केंद्रित है, इसलिए जवाब भी स्वाभाविक रूप से छोटे होते हैं और खास मददगार नहीं होते
      सामान्य जानकारी के लिए अब मैं Google की खराब हो चुकी search को छोड़कर सीधे Wikipedia पर जाता हूं, लेकिन तकनीकी विषयों को कितनी गहराई तक कवर करना है, इस पर Wikipedia की भी सीमा है। शायद computer internals की details को व्यापक रूप से इकट्ठा करने वाला कोई wiki चाहिए। बिखरे हुए resources बहुत हैं, लेकिन अगर वे एक जगह आ जाएं तो सच में अच्छा होगा
    • मेरे मन में भी लगभग उसी उम्र में ऐसे ही सवाल थे, और Linux source code में कई दिलचस्प जवाब मिले। बेशक उस समय यह कहीं ज्यादा सरल था। खास तौर पर osdev community और Intel system architecture documentation बड़ा turning point बने, और जहां तक याद है 3a या 3b parts में काफी असली माल था
      वह documentation आज दुनिया कैसी है, इससे ज्यादा यह बताता है कि दुनिया कैसी हो सकती है। OSDEV करने पर 32-bit processors द्वारा PAE से 36-bit addressing करने का तरीका, 64-bit processors द्वारा और पैसा निकालने के लिए 52-bit addressing करने का तरीका जैसी कई मजेदार चीजें सीखने को मिलती हैं
      यह भी समझ आता है कि computer 16-bit mode से शुरू होकर long mode तक पहुंचने के लिए system-level assembly acrobatics क्यों करता है, और 8-bit mode क्यों बचा हुआ है। अगर आपको binary loading सीखना अच्छा लगा था, तो अभी भी हैरान करने वाली बहुत चीजें हैं। उदाहरण के लिए, 64-bit mode में भी memory segmentation मौजूद है, लेकिन long mode में flat mapping को force किया जाता है
    • शानदार काम। operating system development शुरू करने के लिए अच्छा resource है, details बहुत हैं लेकिन पचाने में आसान है। Chapter 2 note #2 के आखिरी हिस्से में थोड़ा सुधार अच्छा रहेगा। कुछ programming languages के async paradigm में cooperative multitasking होने की बात झलकनी चाहिए। किसी process के अंदर cooperative multitasking इस्तेमाल करना आम तौर पर सुरक्षित माना जाता है, लेकिन यह desirable है या नहीं, वह अलग सवाल है। मेरी जानकारी में Erlang robustness के लिए preemptive ही रखता है

  • मुझे ऐसे resources पसंद हैं। इन दिनों मैं RISC-V दुनिया में कदम रख रहा हूं, और साफ दिखता है कि free और open-source software को आगे बढ़ाने वाले लोगों को नए-नए single-board computers पर software सही से चलाने के लिए ऐसा ज्ञान चाहिए

    • वैसे RISC-V instruction encoding, Thumb-2 जैसी कुछ चीजों को छोड़ दें तो, explore करने लायक चीजों में काफी अजीब है। इसे ऐसा बनाने के अच्छे कारण थे, लेकिन अगर आप hex dump पढ़ने की सोच रहे हैं तो RISC-V आपको आसानी से नहीं छोड़ेगा। भले ही ज्यादातर दूसरे पहलुओं से यह simple हो
    • अगर bachelor's या उससे ऊपर पढ़ाई की है, तो मुझे लगता है programmers को आम तौर पर यह सब पहले से पता होता है। कम से कम अगर आपने computer architecture और operating systems classes skip नहीं की हों
      मेरे मामले में computer कैसे काम करता है यह सीखते हुए instruction set architecture define करना, simulator और assembler implement करना, और assembly खुद लिखना आम बात थी। ज्यादा मेहनती लोग इसे FPGA पर implement करते हैं या LLVM backend लिखते हैं
      operating systems में भी यही बात है। खुद kernel implement करके सीखना, या कम से कम मौजूदा kernel modify करना, काफी common process है

  • अगर आप बहुत basic level पर computer कैसे काम करता है, यह और जानना चाहते हैं, तो Charles Petzold की किताब Code की मैं सच में सिफारिश करता हूं। यह first principles से शुरू करके काफी ऊंचे level तक जाती है

    • अगर आप बनाकर सीखना पसंद करते हैं, तो Nandgame https://nandgame.com भी अच्छा है

  • इस resource की अच्छी बातों में से एक यह है कि जानकारी जुटाने की प्रक्रिया में expected vs actual learning outcomes को दिखाता है। जैसे “y की वजह से मुझे लगा था कि x होगा, लेकिन असल में b की वजह से a था!”
    गलतफहमियां हटाना अक्सर नया ज्ञान बनाने का अहम चरण होता है, और जब लेखक यह स्वीकार करता है कि reader को जानकारी process करते हुए अपनी गलतफहमियों से पार पाना होगा, तो मदद मिलती है। यह “यही सही जवाब है, और अगर आपने अलग सोचा तो आप बेवकूफ हैं” वाले रवैये से कहीं ज्यादा reader-friendly है

  • Chapter 6 में fork() return value की explanation गलत है। जो लिखा है उसके उलट, parent में child का PID return होना चाहिए और child में 0 return होना चाहिए। मैंने इस हिस्से के लिए pull request बनाया है

    • बहुत धन्यवाद, मेरी गलती थी। code example ठीक करके merge कर दिया

  • add eax, 512 को 05 00 02 00 00 में translate किया जाता है—इस explanation में कहा गया है कि पहला byte 05, EAX register में 16-bit number जोड़ने वाला opcode है और बाकी bytes little-endian में 512 (0x200) हैं
    लेकिन यह explanation 5-byte instruction में से सिर्फ़ पहले 3 bytes को explain करता है। बचे हुए 00 क्या हैं, यह समझ नहीं आ रहा। शायद यह लिखना था कि opcode EAX में 32-bit number जोड़ता है?

    • “he” नहीं, “she” है, और हाँ। लगता है उस हिस्से में 32-bit लिखना चाहिए था। अच्छी पकड़
    • अगर x86 की बात हो रही है, तो सही है। eax register 32-bit चौड़ा होता है, और उसी register के निचले 16-bit को ax कहा जाता है

  • अच्छा लेख है। एक self-taught web developer के रूप में मुझे ऐसे resources बहुत valuable लगते हैं। ये कई abstractions से बाहर निकलकर यह ज़्यादा ठोस तौर पर समझने में मदद करते हैं कि चीज़ें असल में कैसे काम करती हैं

  • अच्छा resource लगता है, core मुद्दे पर काफ़ी जल्दी आता है, और थोड़ा मज़ेदार भी है। जितना मैंने सोचा था, उतना “monad tutorial” जैसा नहीं है। आगे पढ़ने का सोच रहा हूँ

    • अच्छा लगा कि आपको पसंद आया। बाद में कोई feedback हो तो बताइएगा

  • अच्छा resource है। हालांकि kernel को लेकर एक सवाल रह जाता है। [0] में बताया गया है कि shebang kernel में handle होता है और पूरा file load नहीं करता, बल्कि buf से लेता है, इसलिए वह हमेशा buf length पर truncate हो जाता है
    4 साल पहले किसी को kernel द्वारा 128 characters से लंबे paths काट देने से चिढ़ हुई, तो उसने buffer size को दोगुना करके truncation point भी दोगुना कर दिया। इसलिए आज Linux पर अगर shebang line 256 characters से ज़्यादा हो, तो 256 के बाद सब कुछ पूरी तरह गायब हो जाता है
    समझ नहीं आता कि कोई किसी के file path को चुपचाप क्यों काटेगा। और वह भी kernel को तो बिल्कुल ऐसा नहीं करना चाहिए। 256-byte का file path अव्यावहारिक हो सकता है, लेकिन 256-byte का path+argument string किसी न किसी दिन लगभग पक्का बनेगा। scripts को चुपचाप तोड़ना गलत है
    [0]: https://cpu.land/how-to-run-a-program

    • लेखक के तौर पर मैं इससे पूरी तरह सहमत हूँ। shebang की limits समझने के लिए kernel की execution logic तक जानना ज़रूरी नहीं होना चाहिए। यह बेवकूफ़ाना design है, और शायद मुझे इस बात पर और ज़ोर देना चाहिए था
      कुछ साल पहले किसी ने बहुत लंबे shebang के case में कम-से-कम चुपचाप fail होने के बजाय साफ़ तौर पर fail कराने के लिए kernel patch की कोशिश की थी। लेकिन NixOS में समस्या आ गई। Nix के अंदाज़ में, वह पहले से ही बहुत लंबे nix-store paths वाले excessive shebangs काफ़ी इस्तेमाल कर रहा था। पहले वे चुपचाप truncate होते थे लेकिन फिर भी काम करते थे; अचानक वे सभी scripts fail होने लगे और backward compatibility टूट गई। इसलिए patch revert करना पड़ा, और उसके बाद वैसा कोई बदलाव नहीं आ पाया
      details के लिए https://lwn.net/Articles/779997/ देखें
    • shebang में complex arguments नहीं डालने चाहिए। shebang का काम current file के interpreter location को बताना है
      shebang अपने-आप एक से ज़्यादा arguments भी ठीक से handle नहीं कर पाता। अगर #!/bin/program -args somescript लिखा जाए, तो यह ['/bin/program','-args somescript'] में split होता है, जो लगभग हमेशा desired result नहीं होता। यह Linux-specific है, और shebang सभी Unix पर universally portable भी नहीं है
      अगर complex काम करना है, तो #!/bin/sh रखें और current file से ज़रूरी arguments के साथ exec करना बेहतर है
      link में एक बात छूट गई है कि env का इस्तेमाल करके current path में interpreter खोजा जा सकता है। उदाहरण के लिए #!/usr/bin/env python3 user के इस्तेमाल वाले python3 को location जाने बिना ढूंढ देता है
      यह virtual environments में चलने वाली scripts के लिए useful हो सकता है, जहाँ Python interpreter के लिए PATH override करके काम कराया जाता है। हालांकि installed programs में ऐसा नहीं करना चाहिए। installed program को यह control नहीं करने देना चाहिए कि user कौन-सा interpreter इस्तेमाल करेगा, इसलिए absolute path इस्तेमाल करना चाहिए
      env में -S option होता है, जिससे इस limit से निपटने के लिए एक single string से command line parse की जा सकती है। फिर भी, वर्षों से shebang line में tricks से बचते आए किसी व्यक्ति के तौर पर, यह ज़्यादा-से-ज़्यादा doubtful practice लगती है
    • यह ज़्यादा हैरान करने वाली बात है कि buffer को disk block size के बराबर set नहीं किया गया। आम तौर पर वह 512 bytes होता है, लेकिन हमेशा नहीं