c - विधानसभा में अक्सर कार्यक्रम क्यों नहीं लिखे जाते हैं?




programming-languages assembly (20)

$$$

A company hires a developer to help turn code into $$$. The faster that useful code can be produced, the faster the company can turn that code into $$$.

Higher level languages are generally better at churning out larger volumes of useful code. This is not to say that assembly does not have its place, for there are times and places where nothing else will do.

ऐसा लगता है कि असेंबली प्रोग्रामिंग अधिक समय लेती है और उच्च स्तर की भाषा जैसे सी के रूप में प्रोग्राम करना अधिक कठिन होता है। इसलिए ऐसा लगता है या माना जाता है कि इन कारणों से उच्च स्तर की भाषा में लिखना बेहतर है और बेहतर पोर्टेबिलिटी के कारण के लिए।

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

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

यदि पोर्टेबिलिटी कोई मुद्दा नहीं है, तो वास्तव में, सीए के पास एक अच्छा असेंबलर जैसे NASM क्या होगा?

संपादित करें: बस इंगित करने के लिए। जब आप असेंबली में लिख रहे हों, तो आपको केवल निर्देश कोड में लिखना नहीं है। आप प्रोग्राम को अधिक मॉड्यूलर, अधिक रखरखाव और पढ़ने में आसान बनाने के लिए विभिन्न abstractions बनाने के लिए मैक्रोज़ और प्रक्रियाओं और अपने स्वयं के सम्मेलनों का उपयोग कर सकते हैं। यह वह जगह है जहां अच्छी असेंबली लिखने के बारे में परिचित होना आता है।


असेंबलर योग्यता का एक उचित स्तर एक उपयोगी कौशल है, खासकर यदि आप किसी भी प्रकार के सिस्टम स्तर या एम्बेडेड प्रोग्रामिंग पर काम करते हैं, तो इतना नहीं कि आपको इतना असेंबलर लिखना है, लेकिन क्योंकि कभी-कभी यह समझना महत्वपूर्ण है कि बॉक्स वास्तव में क्या कर रहा है । यदि आपके पास असेंबलर अवधारणाओं और मुद्दों की निम्न-स्तर की समझ नहीं है, तो यह बहुत मुश्किल हो सकता है।

हालांकि, वास्तव में असेंबलर में अधिक कोड लिखने के लिए, ऐसा कई कारण हैं जिनसे यह बहुत कुछ नहीं हुआ है।

  • बस कोई (लगभग) जरूरत नहीं है। शुरुआती सिस्टम प्रारंभिकरण और संभवत: सी फ़ंक्शंस या मैक्रोज़ में छिपे हुए कुछ असेंबलर टुकड़े जैसे कुछ के अलावा, सभी बहुत कम-स्तरीय कोड जो एक बार असेंबलर में लिखे गए हैं, को सी या सी ++ में कोई कठिनाई नहीं हो सकती है।

  • उच्च स्तरीय भाषाओं में कोड (यहां तक ​​कि सी और सी ++) कार्यक्षमता को कम लाइनों में कार्यक्षमता प्रदान करता है, और वहां काफी अनुसंधान दिखाता है कि बग की संख्या स्रोत कोड की रेखाओं की संख्या से संबंधित है। हां, एक ही समस्या, जो असेंबलर और सी में हल हो जाती है, के पास असेंबलर में अधिक बग होगा क्योंकि यह अब लंबा है। एक ही तर्क उच्च स्तर की भाषाओं जैसे पर्ल, पायथन इत्यादि के कदम को प्रेरित करता है।

  • असेंबलर में लिखना, आपको समस्या के हर पहलू से निपटना होगा, विस्तृत मेमोरी लेआउट, निर्देश चयन, एल्गोरिदम विकल्प, ढेर प्रबंधन इत्यादि से। उच्च स्तर की भाषाएं इसे आपसे दूर ले जाती हैं, यही कारण है कि इतनी घनत्व एलओसी की शर्तें

अनिवार्य रूप से, उपरोक्त सभी एएसएल बनाम सी या कुछ अन्य भाषा में आपके लिए उपलब्ध अमूर्तता के स्तर से संबंधित हैं। असेंबलर आपको अपने सभी अवशेषों को बनाने के लिए मजबूर करता है, और उन्हें अपने स्वयं के अनुशासन के माध्यम से बनाए रखने के लिए मजबूर करता है, जहां सी जैसी मध्य-स्तर की भाषा, और विशेष रूप से उच्च स्तर की भाषाएं, आपको बॉक्स से बाहर निकलने के साथ-साथ साथ ही साथ अपेक्षाकृत आसानी से नए बनाने की क्षमता।


इसी कारण से हम बाथरूम के बाहर नहीं जाते हैं, या हम लैटिन या अरामाईक क्यों नहीं बोलते हैं।

प्रौद्योगिकी साथ आता है और चीजों को आसान और अधिक सुलभ बनाता है।

संपादित करें - लोगों को अपमानित करने के लिए, मैंने कुछ शब्द हटा दिए हैं।


एएसएम की खराब सुगमता है और उच्च स्तर की भाषाओं की तुलना में वास्तव में बनाए रखने योग्य नहीं है

इसके अलावा, सी जैसी अन्य लोकप्रिय भाषाओं की तुलना में बहुत कम एएसएम डेवलपर हैं

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

क्या होगा यदि अगले सीपीयू में दो बार रजिस्ट्रार हैं?

इस सवाल के विपरीत होगा: संकलक क्या कार्यक्षमता प्रदान करते हैं?

मुझे संदेह है कि आप अपने एएसएम को gcc -O3 से बेहतर अनुकूलित / अनुकूलित करना चाहते हैं।


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

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

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


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

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

हमारी समस्याएं अब भी काफी अलग हैं। 1 9 86 में मैं यह पता लगाने की कोशिश कर रहा था कि स्क्रीन पर कुछ सौ पिक्सल डालने वाले छोटे कार्यक्रमों से थोड़ा अधिक गति कैसे प्राप्त करें; मैं चाहता था कि एनीमेशन कम झटकेदार हो। असेंबली भाषा के लिए एक उचित मामला। अब मैं यह समझने की कोशिश कर रहा हूं कि बंधक के लिए अनुबंध भाषा और सर्विसर पॉलिसी के आसपास अमूर्तताओं का प्रतिनिधित्व कैसे किया जाए, और मैं ऐसी भाषा को पढ़ूंगा जो व्यवसायिक लोगों की भाषा के करीब दिखती है। एलआईएसपी मैक्रोज़ के विपरीत, असेंबली मैक्रोज़ नियमों के तरीके में बहुत अधिक लागू नहीं करते हैं, भले ही आप एक अच्छे असेंबलर में डीएसएल के करीब कुछ उचित रूप से प्राप्त कर सकें, फिर भी यह सभी प्रकार के क्विर्क के लिए प्रवण होगा जो ' अगर मुझे रूबी, बू, लिस्प, सी # या यहां तक ​​कि एफ # में एक ही कोड लिखा गया तो मुझे समस्याएं नहीं आतीं।

यदि आपकी समस्याओं को प्रभावी असेंबली भाषा में व्यक्त करना आसान है, हालांकि, आपके लिए अधिक शक्ति।


खैर मैं "पुराने दिनों में" बहुत सारी सभाएं लिख रहा हूं, और मैं आपको आश्वस्त कर सकता हूं कि जब मैं उच्च स्तर की भाषा में प्रोग्राम लिखता हूं तो मैं अधिक उत्पादक हूं।


दूसरों ने जो कुछ कहा है, उससे अधिकांश।

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

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


पोर्टेबिलिटी हमेशा एक मुद्दा है - अगर अब नहीं, कम से कम अंततः। प्रोग्रामिंग उद्योग प्रति वर्ष पुराने सॉफ्टवेयर को अरबों खर्च करता है, जिस समय लिखा गया था, उसमें "स्पष्ट रूप से" कोई पोर्टेबिलिटी समस्या नहीं थी।


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

सी को 'उच्च स्तरीय असेंबली' के रूप में सोचना संभव है, लेकिन इसके ऊपर कुछ कदम प्राप्त करें और आप एक अलग दुनिया में हैं। सी # में आप इसे लिखने के बारे में दो बार नहीं सोचते हैं:

foreach (string s in listOfStrings) { /* do stuff */ }

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

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

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


मुझे लगता है कि x86 (_64) पर भी एएसएम उन मामलों में समझ में आता है जहां आप संकलक का अनुकूलन करने के लिए मुश्किल निर्देशों का उपयोग करके बहुत कुछ प्राप्त करते हैं। उदाहरण के लिए x264 इसके एन्कोडिंग के लिए बहुत सी एएसएम का उपयोग करता है, और गति लाभ बहुत बड़ा है।


मैं अब लगभग एक महीने तक असेंबली में प्रोग्रामिंग कर रहा हूं। मैं अक्सर सी में कोड का एक टुकड़ा लिखता हूं और फिर इसे सहायता करने के लिए इसे असेंबली में संकलित करता हूं। शायद मैं सी कंपाइलर की पूर्ण अनुकूलन शक्ति का उपयोग नहीं कर रहा हूं लेकिन ऐसा लगता है कि मेरे सी एएसएम स्रोत में अनावश्यक संचालन शामिल है। इसलिए मुझे यह देखना शुरू हो रहा है कि एक अच्छा असेंबली कोडर बेहतर प्रदर्शन करने वाला एक अच्छा सी कंपाइलर की बात हमेशा सत्य नहीं होती है।

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

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

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


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

उस ने कहा, मुझे लगता है कि विधानसभा के लिए अभी भी वैध उपयोग हैं। उदाहरण के लिए, मेरे पास सिमड का उपयोग करके बड़ी मात्रा में डेटा प्रोसेसिंग के लिए कई सुंदर अनुकूलित असेंबली दिनचर्या हैं और पागलपन के बाद "हर बिट पवित्र है" [उद्धरण V.Stob] दृष्टिकोण। (लेकिन ध्यान दें कि बेवकूफ असेंबली कार्यान्वयन अक्सर आपके लिए एक संकलक उत्पन्न करने की तुलना में बहुत खराब होता है।)


मैंने 6502, जेड 80, 680 9 और 8086 चिप्स के लिए असेंबलर के शेडलोड लिखे हैं। जैसे ही सी संकलक प्लेटफार्मों को संबोधित कर रहे थे, उनके लिए मैं जल्द ही ऐसा करना बंद कर दिया, और तुरंत कम से कम 10x अधिक उत्पादक बन गया। सबसे अच्छे प्रोग्रामर उन तर्कों का उपयोग करते हैं जो वे तर्कसंगत कारणों से उपयोग करते हैं।


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

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


सी एक मैक्रो असेंबलर है! और यह सबसे अच्छा है!

It can do nearly everything assembly can, it can be portable and in most of the rare cases where it can't do something you can still use embedded assembly code. This leaves only a small fraction of programs that you absolutely need to write in assembly and nothing but assembly.

And the higher level abstractions and the portability make it more worthwhile for most people to write system software in C. And although you might not need portability now if you invest a lot of time and money in writing some program you might not want to limit yourself in what you'll be able to use it for in the future.


जब आप असेंबली में लिख रहे हों, तो आपको केवल निर्देश कोड में लिखना नहीं है। आप प्रोग्राम को अधिक मॉड्यूलर, अधिक रखरखाव और पढ़ने में आसान बनाने के लिए विभिन्न abstractions बनाने के लिए मैक्रोज़ और प्रक्रियाओं और अपने स्वयं के सम्मेलनों का उपयोग कर सकते हैं।

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

क्या इससे आपके प्रश्न का उत्तर मिलता है? ;-)

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

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

यह बैग में कई आदमी-वर्ष के काम के साथ था, जो असेंबलर प्रौद्योगिकी, पुस्तकालयों आदि को विकसित करता था। माना जाता है कि इनमें से अधिकतर इसे पोर्टेबल बनाने में चला गया, अगर यह केवल एक आर्किटेक्चर को लक्षित कर रहा था तो ऑल-गायन ऑल-डांसिंग असेंबलर बहुत आसान होता।

संक्षेप में: आपको सी पसंद नहीं हो सकता है, लेकिन इसका मतलब यह नहीं है कि सी का उपयोग करने का प्रयास कुछ बेहतर तरीके से आने के प्रयास से अधिक है।


As others mentioned before, the reason for any tool to exist is how efficiently it can work. As HLLs can accomplish the same jobs as many lines of asm code I guess it's natural for assembly to be superseded by other languages. And for the close-to-hardware fiddling - there's inline assembly in C and other variants as per language. Dr. Paul Carter in says in the PC Assembly Language

"...a better understanding of how computers really work at a lower level than in programming languages like Pascal. By gaining a deeper understanding of how computers work, the reader can often be much more productive developing software in higher level languages such as C and C++. Learning to program in assembly language is an excellent way to achieve this goal."

We've got introduction to assembly in my college courses. It'll help to clear concepts. However I doubt any of us would write 90% of code in assembly. How relevant is in-depth assembly knowledge today?


Flipping through these answers, I'd bet 9/10 of the responders have never worked with assembly.

This is an ages old question that comes up every so often and you get the same, mostly misinformed answers. If it weren't for portability, I'd still do everything in assembly myself. Even then, I code in C almost like I did in assembly.


People seem to forget that there is also the other direction.

Why are you writing in Assembler in the first place? Why not write the program in a truly low level language?

के बजाय

mov eax, 0x123
add eax, 0x456
push eax
call printInt

you could just as well write

B823010000
0556040000
50 
FF15.....

That has so many advantages, you know the exact size of your program, you can reuse the value of instructions as input for other instructions and you do not even need an assembler to write it, you can use any text editor...

And the reason you still prefer Assembler about this, is the reason other people prefer C...







assembly