असेंबली लैंग्वेज प्रोग्रामिंग पर विचार

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


हालांकि, सामान्य पुस्तकें होनी चाहिए, "स्लैग" के पहाड़ के नीचे सबसे अधिक संभावना है, मुझे बस उन्हें नहीं मिला। इसलिए, आर्किटेक्चर, मेनेमिक्स और सभी प्रकार के ट्रिक्स "2 उंगलियों से एक अंजीर को कैसे ढालना" के वैश्विक विवरण के साथ ज्ञान भरने से पहले, हम "वैचारिक" दृष्टिकोण से विधानसभा भाषा प्रोग्रामिंग के मुद्दे पर संपर्क करेंगे।

सुखद जीवन?

एक छोटी सी टिप्पणी, बाद में पाठ में हम एक वर्गीकरण का उपयोग करेंगे जो वर्तमान में व्यापक रूप से भिन्न है। हालाँकि, यह "सच्चाई के रंग के बारे में बहस" का एक कारण नहीं है, यह केवल इस रूप में है कि प्रोग्रामिंग पर लेखक के दृष्टिकोण को समझाना आसान है।

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

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

लेकिन इतनी अन्य भाषाओं के बारे में क्या? एक नियम के रूप में, ये पहले से ही "म्यूटेंट" हैं। उदाहरण के लिए, टाइप किए गए और ऑटोमेटन दृष्टिकोण के मिश्रण ने "ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग" दिया।

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

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

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

दूर जंगल में, घना

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

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


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

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

• विशेष रजिस्टर (RON - सामान्य प्रयोजन रजिस्टर - जैसे अनुपस्थित हैं: अर्थात, हम EDI से मान द्वारा GS रजिस्टर की सामग्री को गुणा करने और EDX में परिणाम प्राप्त करने के लिए एक आदेश का उपयोग नहीं कर सकते हैं: ECX जोड़ी, या EDI की जोड़ी से मान को विभाजित करें: ESI सामग्री में पंजीकृत करता है। EAX रजिस्टर);
• कुछ रजिस्टर हैं;
• एक ढेर;
• मेमोरी सेल वहां संग्रहीत मूल्य के प्रकार पर कोई जानकारी नहीं देता है।

दूसरे शब्दों में, एक बड़े रजिस्टर फ़ाइल के साथ प्रोसेसर के लिए उपयोग की जाने वाली प्रोग्रामिंग विधियाँ, कई स्वतंत्र स्टाॅक आदि के लिए समर्थन के साथ। अधिकांश भाग x86 पर प्रोग्रामिंग करते समय लागू नहीं होते हैं।

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

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

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

क्या करें?

विधानसभा भाषा प्रोग्रामिंग में 15 साल के विराम पर विचार करते हुए प्रारंभिक निष्कर्ष।
सबसे पहले, कार्यक्रम के मॉड्यूल या भागों के बारे में। सामान्य मामले में, यह विधानसभा भाषा में कार्यक्रम के दो प्रकार के कार्यकारी मॉड्यूल को उजागर करने के लायक है - "ऑपरेशन" और "उपप्रोग्राम"।

• "ऑपरेशन" से हमारा तात्पर्य एक ऐसे मॉड्यूल से है जो एक "परमाणु" क्रिया करता है और इसके निष्पादन के लिए कई मापदंडों की आवश्यकता नहीं होती है (उदाहरण के लिए, संपूर्ण स्क्रीन को साफ़ करने का संचालन या किसी संख्या श्रृंखला के माध्यिका की गणना का संचालन आदि)।
• एक "उपप्रोग्राम" को एक कार्यात्मक मॉड्यूल कहा जाना चाहिए, जिसके लिए उचित कार्यप्रणाली, बहुत सारे इनपुट पैरामीटर (2x-3x से अधिक) की आवश्यकता होती है।

और यहाँ यह अनिवार्य और कार्यात्मक भाषाओं के अनुभव का मूल्यांकन करने योग्य है। उन्होंने हमें 2 मूल्यवान उपकरण दिए हैं जिनका उपयोग किया जाना चाहिए: "डेटा संरचना" (या, उदाहरण के लिए, REXX - यौगिक / पूरक चर) और "गैर-डेटा स्थिरता"।

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

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

«» , « », , – « ». , (, , BCD, ..) /. , , , «» , — . , , .

, , . , 0- ( ), ( , ) , , , «» .