सी, भाग 2 में बाहरी डिवाइस रजिस्टरों के साथ काम करना

आधी रात आ गई और शेहरजादा ने अपने स्वीकृत भाषण जारी रखे

शुरू करने के लिए, पिछले लेख पर एक टिप्पणी - मैंने खुद को ASSERT के बारे में अनादरपूर्वक बोलने की अनुमति दी - मैं अपनी स्थिति समझाऊंगा। मुझे यह वास्तव में पसंद नहीं है। ASSERT में सत्यापन केवल निष्पादन चरण में किया जाता है, संकलन चरण में सत्यापन अधिक प्रभावी होता है। मुझे एक डिजाइन के अस्तित्व के बारे में पीएम को सूचित किया गया था जो आपको संकलन चरण में आवश्यक जांच करने की अनुमति देता है (मैंने जाँच की - यह वास्तव में काम करता है), मुझे लगता है कि इस विषय पर एक पोस्ट जल्द ही सैंडबॉक्स में दिखाई देगा।

तो, हम जारी रखते हैं ...

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



उदाहरण के लिए, एक बाहरी डिवाइस पर विचार करें जिसका नियंत्रण रजिस्टर है, और रजिस्टर के विभिन्न बिट्स विभिन्न कार्यों का प्रदर्शन करते हैं, अर्थात् कम (शून्य) बिट में डिवाइस व्यस्त ध्वज होता है (0 - डिवाइस स्वतंत्र है और अगले कमांड को निष्पादित करने के लिए तैयार है, 1 - डिवाइस व्यस्त है कुछ कमांड प्रसंस्करण) , और 3 अंक, 30..28 को वरिष्ठता में दूसरे से शुरू। (हम मानते हैं कि हमारे पास 32-बिट शब्द है), कमांड कोड शामिल हैं (यदि यह निर्माण आपको तर्कसंगत नहीं लगता था, तो आपने वास्तविक रजिस्टर विवरण नहीं देखा था)। हम C भाषा का उपयोग करके इस तरह के रजिस्टर के व्यक्तिगत क्षेत्रों में अपील को कैसे व्यवस्थित कर सकते हैं? .. इसके अलावा, यदि हम किसी एक फ़ील्ड को बदलते हैं, तो रजिस्टर के बाकी बिट्स को नहीं बदलना चाहिए।

पहली बात जो दिमाग में आती है (और अक्सर केवल एक चीज जो वहां रहती है) बिट मास्क है। उपरोक्त मामले के लिए, हमारे पास कुछ इस तरह होगा:

#define IO_STATUS_CMD_MASK 0x70000000 #define IO_STATUS_CMD_BIT 28 #define IO_STATUS_FLAG_MASK 0x01 while (*pio_status & IIO_STATUS_FLAG) {}; *pio_status=(*pio_status & ~IO_STATUS_CMD_MASK) | ((command << IO_STATUS_CMD_BIT) & IO_STATUS_CMD_MASK);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

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

 #define DATA_SET(ADR,MASK,BIT,DATA) (ADR)=((ADR) & ~(MASK)) | (((DATA) <<(BIT)) & (MASK)) DATA_SET(*pio_status,IO_STATUS_CMD_MASK,IO_STATUS_CMD_BIT,command);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

 #define LOWBIT(MASK) (((~(MASK)-1)) & (MASK)) #define LOWBIT(MASK) (~(MASK << 1) & (MASK)) #define LOWBIT(MASK) (~(MASK)+1) & (MASK)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, कठिन (मैं सफल नहीं हुआ), कम बिट संख्या को उजागर करने वाला एक सुंदर मैक्रो। लेकिन इस तरह के एक बिटमास्क हमारे लिए पर्याप्त है, और मूल्य हस्तांतरण मैक्रो का कोड थोड़ा बदल जाएगा

 #define DATA_SET(ADR,MASK,DATA) (ADR)=((ADR) & ~(MASK)) | (((DATA) * LOWBIT(MASK)) & (MASK)) DATA_SET(*pio_status,IO_STATUS_CMD_MASK,command);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

 DATA_SET(*pio_status,IO_STATUS_FLAG_MASK,command);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, क्योंकि कंपाइलर हमारे लिए कुछ भी सत्यापित नहीं कर सकता है। बेशक, आप एक और मैक्रो लिख सकते हैं

 #define IO_CMD_SET(DATA) DATA_SET(*pio_status,IO_STATUS_CMD_MASK,DATA) IO_CMD_SET(command);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, लेकिन बहुत जल्दी इस तरह के मैक्रोज़ बहुत अधिक हो जाएंगे और त्रुटि की संभावना फिर से पैदा होती है। एक और खामी टाइप चेकिंग की कमी है, यानी एक ऑपरेशन जैसा

 IO_CMD_SET(36);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

संकलक किसी भी संदेह का कारण नहीं होगा, हालांकि निष्पादन का परिणाम आपको अप्रिय रूप से आश्चर्यचकित कर सकता है।

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

 #pragma bitfields = disjoint_types //  ,      #pragma bitfields = reversed //  ,     
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

तब प्रश्न में रजिस्टर की संरचना निम्नानुसार वर्णित की जा सकती है:

 #pragma bitfields=reverse typedef struct { unsigned :1; //    (31) unsigned code:3; // (30..28) unsigned : 27; //  27  (27..1) unsigned flag:1; // (0 -  ) } tIO_STATUS; #pragma bitfields=default volatile tIO_STATUS * const pio_status = (tIO_STATUS *) (IO_ADR);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

नोट: उदाहरण की पारमार्थिक रेखा फ़ील्ड को डिफ़ॉल्ट मान में रखने की विधा लौटाती है, यदि बाद में ऐसे टुकड़े होते हैं जिनके लेखकों को उनकी परिभाषा से पहले प्रज्ञा सहित चिंता नहीं थी (लेकिन हम ऐसा नहीं हैं, हम विवेकपूर्ण हैं)। हम इस पद्धति की खामी पर ध्यान देते हैं - हमें मैन्युअल रूप से भरे जाने वाले क्षेत्रों की लंबाई की गणना करनी चाहिए (बाद में इस पर अधिक) और फिर फायदे की सूची पर जाएं: हमें कोई मास्क और बिट्स निर्धारित नहीं करना चाहिए (कंपाइलर हमारे लिए सब कुछ करेगा), इसके अलावा, वह रिकॉर्ड की जांच करेगा वैधता पर निरंतर डेटा फ़ील्ड में। रजिस्टर फ़ील्ड अब मानक भाषा टूल का उपयोग करके एक्सेस किए जाते हैं

 while (pio_status->flag) {}; poi_status->code=3;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, और ऑटोफिल और टाइपिंग का काम, यानी ऑपरेटर

 pio_status->code=34;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

संकलक से चेतावनी प्राप्त करेगा।

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

 *pio_status=(*pio_status & ~(IO_STATUS_CMD_MASK | IO_STATUS_FLAG_MASK)) | ((command << IO_STATUS_CMD_BIT) & IO_STATUS_CMD_MASK) | (IO_STATUS_FLAG_MASK * flagset);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

किसी भी तरह से रखरखाव में कठिनाइयों के कारण उपयोग के लिए अनुशंसित नहीं किया जा सकता है। फिर भी, यदि उनके लिए कोई आवश्यकता है, अर्थात्, बाहरी उपकरण की सुविधाओं द्वारा खेतों तक एक साथ पहुंच आवश्यक है, तो प्रकार के निर्माण

 #define WORD(adr) *(int*)(adr) WORD(pio_status)=WORD(pio_status) & ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हमें रस्सी को आवश्यक आकार तक विस्तारित करने की अनुमति देगा, हालांकि व्यक्तिगत रूप से, ऐसी स्थिति में, मैं एक अस्थायी संरचना बनाना पसंद करूंगा, इसे संशोधित करूंगा, और फिर इसे रजिस्टर में भेजूंगा,

 tIO_SATUS tmp; tmp=*pio_status; //      tmp.code=command; tmp.flag=flagset; *pio_status=tmp;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

लेकिन कभी-कभी यह दक्षता के कारणों के लिए अस्वीकार्य हो सकता है। एक और टिप्पणी - यदि आपको ऐसे ऑपरेटरों की आवश्यकता है, तो कुछ कठिनाइयां उत्पन्न होंगी, यदि संरचना में आप कुछ क्षेत्रों को कास्ट के रूप में वर्णित करते हैं

 #pragma bitfields=reverse typedef struct { unsigned :1; //    (31) unsigned code:3; // (30..28) unsigned : 27; //  26  (27..2) unsigned const readflag:1; //     (1) unsigned flag:1; // (0 -  ) } tIO_STATUS; #pragma bitfields=default volatile tIO_STATUS * const pio_status = (tIO_STATUS *) (IO_ADR); tIO_STATUS tmp={0,0,1}; //  ,       tmp=*pio_status; //     *(int*)(&tmp)=*(int*)pio_device; //   tmp.code=3; tmp.flag=1; *(int*)(pio_device)=*(int*)(&tmp);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह थोड़ा अनाड़ी लगता है।

खैर, निष्कर्ष में, बिट्स की मैन्युअल गणना से जुड़े नुकसान - जब पोस्ट की कल्पना की गई थी, तो एक भव्य मैक्रो होना चाहिए था जो रजिस्टर का विवरण प्राप्त करता था जैसे

 REGISTR(tIO_STATUS,code[30..28],readflag[1],flag[0])
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

सामान्य निष्कर्ष यह है कि सी भाषा बिट फ़ील्ड बाहरी उपकरणों के रजिस्टरों का वर्णन करने के लिए एक प्रभावी और सुविधाजनक उपकरण है, जो न्यूनतम नियंत्रण उपाय करते समय उपयोग के लिए अत्यधिक अनुशंसित है।

कुछ बार फिर से निकला, इसलिए खेतों को भरने का सवाल (#define VS enum) और तीसरे भाग में संबंधित प्रश्नों में से कुछ को संबोधित किया जाएगा।