X86 बदसूरत क्यों है? दूसरों की तुलना में इसे हीन क्यों माना जाता है? [बन्द है]

Question

हाल ही में मैं कुछ एसओ अभिलेखागार पढ़ रहा हूं और x86 आर्किटेक्चर के खिलाफ बयानों का सामना कर रहा हूं।

• हमें सर्वर और मिनी / मेनफ्रेम और मिश्रित-कोर के लिए अलग-अलग सीपीयू वास्तुकला की आवश्यकता क्यों है? कहते हैं,
  " पीसी वास्तुकला एक गड़बड़ है, कोई भी ओएस डेवलपर आपको बताएगा। "

• क्या विधानसभा भाषा सीखने के लायक है? ( संग्रहीत ) का कहना है कि
  " महसूस करें कि x86 वास्तुकला सबसे भयानक है "

• X86 कोडांतरक सीखने का कोई आसान तरीका? कहते हैं
  " अधिकांश कॉलेज MIPS जैसी किसी चीज़ पर असेंबली सिखाते हैं क्योंकि यह समझना बहुत सरल है, x86 असेंबली वास्तव में बदसूरत है "

और कई और टिप्पणियाँ पसंद हैं

• "अधिकांश आर्किटेक्चर की तुलना में, X86 बहुत बुरी तरह से चूसता है।"

• " यह निश्चित रूप से पारंपरिक ज्ञान है कि X86 MIPS, SPARC और PowerPC से नीच है "

• " x86 बदसूरत है "

मैंने खोज करने की कोशिश की लेकिन कोई कारण नहीं मिला। मुझे शायद x86 बुरा नहीं लगता क्योंकि यह एकमात्र ऐसा आर्किटेक्चर है जिससे मैं परिचित हूं।

क्या कोई कृपया मुझे दूसरों की तुलना में x86 बदसूरत / बुरा / हीन मानने के कारण दे सकता है।

Comments

मैं अब तक के उत्तरों के आधार पर S & A के साथ जा रहा हूं, लेकिन मैं इस बात पर ध्यान दूंगा कि CISC m68k निर्देश सेट के लिए कोई समस्या नहीं है। x86 यह क्या है, और आप इसे रख सकते हैं।

— dmckee --- पूर्व-मध्यस्थ ने बिल्ली का बच्चा

"S & A" क्या है? "M68k निर्देश सेट के लिए CISC कोई समस्या नहीं है।" -- क्यों नहीं?

— पंजे

Motorala 68000 श्रृंखला के चिप्स में एक उच्च CISC वास्तुकला है, लेकिन उनके पास एक समान, काफी ओर्थोगोनल और बहुत आसान निर्देश सेट है। X86 से अंतर क्यों? मुझे नहीं पता। लेकिन ध्यान दें कि निर्देश सेट में चिप में जटिलता और जटिलता के बीच एक बड़ा अंतर है (अर्थात एक इंटरफ़ेस जिसे असेंबली प्रोग्रामर देखता है)।

— dmckee --- पूर्व-मध्यस्थ बिल्ली का बच्चा

एक बहुत ही दिलचस्प सवाल के लिए +1।

— ट्यूरिंग

CISC और RISC ने क्या डिजाइन किया, इसकी अच्छी चर्चा के साथ विभिन्न प्रोसेसर की ऊर्जा दक्षता पर हाल ही में यहां अध्ययन किया गया। extremetech.com/extreme/…

Answer 1

इसके संभावित कारणों में से कुछ:

1. x86 एक अपेक्षाकृत पुराना ISA है (इसके पूर्वज 8086 थे, आखिरकार)
2. x86 कई बार काफी विकसित हुआ है, लेकिन पुराने बायनेरिज़ के साथ पीछे की संगतता बनाए रखने के लिए हार्डवेयर की आवश्यकता होती है। उदाहरण के लिए, आधुनिक x86 हार्डवेयर में अभी भी 16 बिट कोड को मूल रूप से चलाने के लिए समर्थन है। इसके अलावा, कई मेमोरी-एड्रेसिंग मॉडल पुराने प्रोसेसर को उसी प्रोसेसर पर इंटर-ऑपरेट करने की अनुमति देने के लिए मौजूद हैं, जैसे कि रियल मोड, संरक्षित मोड, वर्चुअल 8086 मोड और (amd64) लॉन्ग मोड। यह कुछ भ्रामक हो सकता है।
3. x86 एक CISC मशीन है। लंबे समय तक इसका मतलब था कि यह MIS या ARM जैसी RISC मशीनों की तुलना में धीमी थी, क्योंकि निर्देश हैं डेटा अन्योन्याश्रयता और झंडे हैं, जो अनुदेश स्तर समानता के अधिकांश रूपों को लागू करना मुश्किल बनाते हैं। आधुनिक कार्यान्वयन X86 निर्देशों को RISC- जैसे निर्देशों में अनुवाद करते हैं जिन्हें " माइक्रो-ऑप्स " कहा जाता है हार्डवेयर में लागू करने के लिए इन प्रकार के अनुकूलन को व्यावहारिक बनाने के लिए कवर के तहत " ।
4. कुछ मामलों में, x86 हीन नहीं है, यह सिर्फ अलग है। उदाहरण के लिए, इनपुट / आउटपुट को आर्किटेक्चर के विशाल बहुमत पर मेमोरी मैपिंग के रूप में नियंत्रित किया जाता है, लेकिन x86 पर नहीं। (एनबी: आधुनिक x86 मशीनों में आमतौर पर डीएमए समर्थन के कुछ रूप होते हैं , और मेमोरी मैपिंग के माध्यम से अन्य हार्डवेयर के साथ संवाद करते हैं; लेकिन ए आईएसए में अभी भी I / O निर्देश हैं जैसे INऔर OUT)
5. X86 ISA में बहुत कम वास्तुशिल्प रजिस्टर हैं, जो प्रोग्रामों को स्मृति के माध्यम से राउंड-ट्रिप के लिए मजबूर कर सकते हैं और अधिक से अधिक अन्यथा आवश्यक होगा। इसे करने के लिए आवश्यक अतिरिक्त निर्देश निष्पादन संसाधन लेते हैं जो उपयोगी कार्य पर खर्च किए जा सकते हैं, हालांकि कुशल स्टोर-फ़ॉरवर्डिंगविलंबता को कम रखता है। एक बड़े भौतिक रजिस्टर फ़ाइल पर नाम बदलने के रजिस्टर के साथ आधुनिक कार्यान्वयन उड़ान में कई निर्देश रख सकते हैं, लेकिन 32-बिट x86 के लिए वास्तुशिल्प रजिस्टरों की कमी अभी भी एक महत्वपूर्ण कमजोरी थी। x86-64 की 8 से 16 पूर्णांक और वेक्टर रजिस्टरों में वृद्धि 64 बिट कोड में 32-बिट (अधिक कुशल रजिस्टर-कॉल एबीआई) के साथ तेजी से होने वाले सबसे बड़े कारकों में से एक है, प्रत्येक रजिस्टर की बढ़ी हुई चौड़ाई नहीं। 16 से 32 पूर्णांक रजिस्टरों में और वृद्धि से कुछ मदद मिलेगी, लेकिन उतनी नहीं। (AVX512 32 वेक्टर रजिस्टर में वृद्धि करता है, हालांकि, क्योंकि फ़्लोटिंग-पॉइंट कोड में उच्च विलंबता है और अक्सर अधिक स्थिरांक की आवश्यकता होती है।) ( टिप्पणी देखें )

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

   if (DF==0) 
     *(byte*)DI++ = *(byte*)SI++; 
   else 
     *(byte*)DI-- = *(byte*)SI--;
   

   यह एक लोड, एक स्टोर, और दो जोड़ता है या घटाना (एक फ्लैग इनपुट द्वारा नियंत्रित) है, जिसमें से प्रत्येक एक आरआईएससी मशीन पर अलग निर्देश होगा।

   जबकि MIPS (और इसी तरह के आर्किटेक्चर) सादगी जरूरी नहीं कि उन्हें बेहतर बनाती है, कोडांतरक वर्ग के लिए एक परिचय सिखाने के लिए यह एक सरल ISA के साथ शुरू करने के लिए समझ में आता है । कुछ असेंबली क्लासेस x86 के एक अल्ट्रा-सरलीकृत सबसेट को सिखाते हैं जिसे y86 कहा जाता है , जिसे वास्तविक उपयोग (जैसे कोई शिफ्ट निर्देश) के लिए उपयोगी नहीं होने के बिंदु से परे सरलीकृत किया जाता है, या कुछ सिर्फ मूल x86 निर्देशों को सिखाते हैं।

7. X86 चर-लंबाई वाले ऑपकोड का उपयोग करता है, जो निर्देशों की पार्सिंग के संबंध में हार्डवेयर जटिलता को जोड़ता है। आधुनिक युग में यह लागत लुप्त होती जा रही है क्योंकि सीपीयू कच्ची संगणना की तुलना में मेमोरी बैंडविड्थ द्वारा अधिक से अधिक सीमित हो जाता है, लेकिन कई "x86 कोसने" वाले लेख और दृष्टिकोण उस युग से आते हैं जब यह लागत तुलनात्मक रूप से बहुत बड़ी थी।
   अपडेट २०१६: आनंदटेक ने एक्स ६४ और एएआरच ६४ के तहत ओपकोड साइज के बारे में चर्चा पोस्ट की है ।

---

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

Comments

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

— बिली ओनेल

@ जॉय एडम्स: एआरएम के थम्ब मोड ( en.wikipedia.org/wiki/ARM_altecture#Thumb ) के साथ x86 की चर लंबाई निर्देशों का विरोध करें । थंब मोड एआरएम के लिए काफी छोटे ऑब्जेक्ट कोड में परिणाम देता है क्योंकि छोटे निर्देश सीधे सामान्य निर्देशों पर मैप करते हैं। लेकिन चूंकि बड़े निर्देशों और छोटे लोगों के बीच 1: 1 मैपिंग है, पार्सिंग हार्डवेयर को लागू करना सरल है। X86 की परिवर्तनशील लंबाई के निर्देशों में ये लाभ नहीं हैं क्योंकि वे इस तरह से डिज़ाइन नहीं किए गए थे।

— बिली ओनेल

(६) प्रत्येक कार्यक्रम के लिए प्रत्येक ऑप-कोड का उपयोग करने की आवश्यकता नहीं होती है, लेकिन जब मुझे SSE3 की आवश्यकता होती है, तो मैं इसके लिए खुश हूं।

— क्रिस के

@ क्रिस Kaminski: यह कैसे हार्डवेयर को प्रभावित नहीं करता है? यकीन है, एक आधुनिक पूर्ण आकार के कंप्यूटर पर किसी का ध्यान नहीं जा रहा है, लेकिन अगर मैं एक सेल फोन जैसा कुछ बना रहा हूं, तो मैं लगभग किसी भी चीज़ की तुलना में बिजली की खपत के बारे में अधिक परवाह करता हूं। चर लंबाई opcodes निष्पादन समय में वृद्धि नहीं है, लेकिन डिकोड हार्डवेयर अभी भी संचालित करने के लिए शक्ति की आवश्यकता है।

— बिली ओनेल

कौन सी चीजें हैं जो x86 निर्देश को इतनी बदसूरत बना देती हैं, क्योंकि यह तय नहीं कर सकती है कि यह एक संचायक या रजिस्टर-फाइल आधारित वास्तुकला है (हालांकि यह ज्यादातर 386 के साथ तय किया गया था, जिसने अनुदेश को बहुत अधिक रूढ़िवादी बना दिया था , भले ही 68k प्रशंसक आपको बताएं)।

— नंजलज

Answer 2

मेरे मन में x86 के खिलाफ मुख्य दस्तक इसकी CISC उत्पत्ति है - निर्देश सेट में बहुत अधिक अंतर्निहित अंतर्निर्भरताएं हैं। इन अन्योन्याश्रितताओं को चिप पर निर्देश पुन: व्यवस्थित करने जैसे काम करना मुश्किल हो जाता है, क्योंकि प्रत्येक निर्देश के लिए उन अन्योन्याश्रितियों की कलाकृतियों और शब्दार्थों को संरक्षित किया जाना चाहिए।

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

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

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

वैसे भी, अल्फा एएक्सपी चिप डिजाइनों की 3 या 4 पीढ़ियों से, हार्डवेयर 40 आंतरिक रजिस्टरों के साथ सेटर्टन इंस्ट्रक्शन के शाब्दिक कार्यान्वयन से चला गया और 80 आंतरिक रजिस्टरों के साथ बड़े पैमाने पर आउट ऑफ ऑर्डर निष्पादन इंजन में 32 फ्लोट रजिस्टरों का नामकरण, रजिस्टर का नामकरण, परिणाम अग्रेषण (जहां पिछले निर्देश का परिणाम बाद के निर्देश के लिए भेजा जाता है जो मूल्य पर निर्भर होता है) और सभी प्रकार के जंगली और पागल प्रदर्शन बूस्टर। और उन सभी घंटियाँ और सीटी के साथ, AXP चिप डाई अभी भी उस समय की तुलनीय पेंटियम चिप डाई से काफी छोटी थी, और AXP बहुत तेजी से नरक था।

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

मैंने बहुत से x86 कोडांतरक लिखे हैं और इसकी CISC जड़ों की सुविधा की पूरी तरह से सराहना कर सकता हूँ। लेकिन मैंने पूरी तरह से सराहना नहीं की कि एक्सएक्सएक्स एएक्सपी असेंबलर लिखने में कुछ समय बिताने तक x86 कितना जटिल था। मुझे एक्सपीपी की सादगी और एकरूपता ने हतप्रभ कर दिया था। अंतर बहुत बड़ा है, और गहरा है।

Comments

जब तक आप m68k की व्याख्या नहीं कर सकते, तब तक मैं प्रति CISC को कोसने की कोई बात नहीं सुनूंगा।

— dmckee --- पूर्व-मध्यस्थ ने बिल्ली का बच्चा

मैं m68k से परिचित नहीं हूं, इसलिए मैं इसकी आलोचना नहीं कर सकता।

— dthorpe

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

— बिली ओनेल

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

— dthorpe

@ डोरपोर: यदि आपने जो कुछ भी लिखा है, उससे मैं असहमत हूं। 8086 के बाद से, आपको चिंता करने की ज़रूरत नहीं थी अगर एक के addबाद एक को निष्पादित करना सुरक्षित था add। नियम स्पष्ट हैं। अनुदेश पुन: क्रम से निपटने के लिए भी आपको कोई आवश्यकता नहीं है। जब से 90 के दशक के मध्य में पेंटियम प्रो, सीपीयू आपके लिए करता है। आप जो उल्लेख कर रहे हैं वह 20 साल पहले एक समस्या हो सकती है, लेकिन मुझे आजकल x86 आर्किटेक्चर के खिलाफ इसे रखने का कोई कारण नहीं दिखता है।

— नाथन फेलमैन

Answer 3

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

एक ही युग के अन्य प्रोसेसर (जैसे 6502 परिवार) की भी समान सीमाएँ और विचित्रताएँ हैं। दिलचस्प बात यह है कि 8008 श्रृंखला और 6502 श्रृंखला दोनों का उद्देश्य एम्बेडेड नियंत्रकों के रूप में था। तब भी, एम्बेडेड नियंत्रकों को कोडांतरक लेखक के बजाय असेंबलर में और कई तरह से असेंबली प्रोग्रामर को पूरा करने की उम्मीद की गई थी। (जब आप संकलक के लेखन को पूरा करते हैं तो क्या होता है, इसके लिए वैक्स चिप देखें।) डिजाइनरों ने उनसे सामान्य प्रयोजन कंप्यूटिंग प्लेटफॉर्म बनने की उम्मीद नहीं की थी; यही कारण है कि बिजली आर्च के पूर्ववर्तियों जैसी चीजें किसके लिए थीं। होम कंप्यूटर क्रांति ने निश्चित रूप से बदल दिया।

Comments

+1 के लिए यहां एकमात्र उत्तर जो वास्तव में इस मुद्दे पर ऐतिहासिक पृष्ठभूमि है लगता है।

— बिली ओनेल

याददाश्त हमेशा धीमी रही है। यह संभवतः (अपेक्षाकृत बोलने वाला) आज की तुलना में धीमा है जब मैंने 1982 में Z80s और CP / M के साथ शुरू किया था। विलुप्त होने का केवल विकास का रास्ता नहीं है क्योंकि विलुप्त होने के साथ ही विशेष विकासवादी दिशा बंद हो जाती है। मैं कहूंगा कि x 28 ने अपने 28 साल (अब तक अस्तित्व) में अच्छी तरह से अनुकूलित किया है।

— ओलॉफ फोर्सशेल

स्मृति की गति 8086 के समय के आसपास सीपीयू के साथ समता के करीब पहुंच गई। टेक्सास इंस्ट्रूमेंट्स के 9900 में एक डिज़ाइन है जो केवल इसलिए काम करता है क्योंकि ऐसा हुआ था। लेकिन तब सीपीयू फिर से आगे बढ़ा और वहीं ठहर गया। केवल अब, इसे प्रबंधित करने में सहायता के लिए कैश हैं।

— स्टेटिक्सन

@ ओलोफ़ फोर्शेल: यह 8080 असेंबली कोड में 8086 कोड में अनुवाद कर सकने वाला असेंबलर था। उस दृष्टिकोण से, यह 8080 प्लस एक्सटेंशन था, जैसे आप 8080 को 8008 प्लस एक्सटेंशन के रूप में देख सकते थे।

— डेविड थॉर्नले

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

— डेविड थॉर्नले

Answer 4

मेरे यहाँ कुछ अतिरिक्त पहलू हैं:

ऑपरेशन "ए = बी / सी" पर विचार करें x86 इसे लागू करेगा

  mov eax,b
  xor edx,edx
  div dword ptr c
  mov a,eax

Div निर्देश edx के अतिरिक्त बोनस के रूप में शेष रहेगा।

आरआईएससी प्रोसेसर को पहले बी और सी के पते लोड करने, मेमोरी से रजिस्टरों में बी और सी लोड करने, विभाजन करने और एक के पते को लोड करने और फिर परिणाम को संग्रहीत करने की आवश्यकता होगी। Dst, src सिंटैक्स:

  mov r5,addr b
  mov r5,[r5]
  mov r6,addr c
  mov r6,[r6]
  div r7,r5,r6
  mov r5,addr a
  mov [r5],r7

यहाँ आमतौर पर कोई शेष नहीं रहेगा।

यदि किसी भी चर को बिंदुओं के माध्यम से लोड किया जाना है, तो दोनों अनुक्रम लंबे हो सकते हैं, हालांकि यह आरआईएससी के लिए एक संभावना से कम है क्योंकि इसमें एक या एक से अधिक पॉइंटर्स पहले से ही किसी अन्य रजिस्टर में लोड हो सकते हैं। x86 में कम रजिस्टर होता है इसलिए पॉइंटर के किसी एक में होने की संभावना कम होती है।

फायदा और नुकसान:

RISC निर्देशों को निर्देश निर्धारण में सुधार करने के लिए आसपास के कोड के साथ मिलाया जा सकता है, यह x86 के साथ एक संभावना कम है जो इसके बजाय सीपीयू के अंदर ही यह काम करता है (अनुक्रम के आधार पर अधिक या कम अच्छी तरह से)। ऊपर दिया गया RISC अनुक्रम आमतौर पर एक 32-बिट आर्किटेक्चर पर 28 बाइट्स (प्रत्येक 32-बिट / 4 बाइट चौड़ाई के 7 निर्देश) होगा। यह निर्देश (सात भ्रूण) लाने पर ऑफ-चिप मेमोरी को अधिक काम करने का कारण होगा। सघन x86 अनुक्रम में कम निर्देश होते हैं और यद्यपि उनकी चौड़ाई भिन्न होती है, आप शायद औसतन 4 बाइट्स / निर्देश भी देख रहे हैं। यहां तक ​​कि अगर आपके पास सात फ़िशिंग को गति देने के लिए निर्देश कैश हैं, तो इसका मतलब है कि आपके पास x86 की तुलना में बनाने के लिए तीन अन्य जगहों की कमी होगी।

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

अधिक व्यक्तिगत नोट पर मुझे x86 की तुलना में RISC असेंबली लिखना अधिक कठिन लगता है। मैं इसे C कोड में RISC दिनचर्या लिखकर, उत्पन्न कोड को संकलित और संशोधित करके हल करता हूं। यह एक कोड उत्पादन दृष्टिकोण से अधिक कुशल है और शायद एक निष्पादन दृष्टिकोण से कम कुशल है। उन सभी 32 रजिस्टरों का ट्रैक रखने के लिए। X86 के साथ यह दूसरा तरीका है: "वास्तविक" नामों के साथ 6-8 रजिस्टर समस्या को अधिक प्रबंधनीय बनाता है और अधिक विश्वास पैदा करता है कि उत्पादित कोड अपेक्षा के अनुरूप काम करेगा।

बदसूरत? वह देखने वाले की नजर में है। मैं "अलग" पसंद करता हूं।

Comments

मेरे उदाहरणों में ए, बी और सी को स्मृति-आधारित चर के रूप में देखा जाना चाहिए, न कि तत्काल मूल्यों पर।

— ओलॉफ फोर्सशेल

... "dword ptr" का उपयोग एक चर के आकार को निर्दिष्ट करने के लिए किया जाता है जिसका आकार ज्ञात नहीं है यदि, उदाहरण के लिए, इसे बस बाहरी रूप में घोषित किया गया है या यदि आप आलसी हो गए हैं।

— Olof Forshell

यह पहली बार नहीं है जब मैंने इसे पहले सी में लिखने का सुझाव सुना, और फिर इसे असेंबलर में डिस्टिल किया। यह निश्चित रूप से मदद करता है

— जो प्लांटे

शुरुआती दिनों में सभी प्रोसेसर RISC थे। CISC फेरिक कोर मेमोरी सिस्टम के लिए एक शमन रणनीति के रूप में आया, जो बहुत धीमी गति से थे, इस प्रकार CISC ने कम, अधिक शक्तिशाली निर्देशों के साथ, मेमोरी सबसिस्टम पर कम तनाव डाला, और बैंडविड्थ का बेहतर उपयोग किया। इसी तरह, रजिस्टरों को मूल रूप से संचय करने के लिए ऑन-चिप, इन-सीपीयू मेमोरी स्थानों के रूप में सोचा गया था। आखिरी बार जब मैंने गंभीरता से एक RISC मशीन की शुरुआत की थी, तो 1993 - SPARC और HP Prisim थी। स्पार्क बोर्ड भर में भयानक था। प्रिज़िम 20x तक उपवास के रूप में ऐड / सब / म्यू पर 486 था, लेकिन ट्रांसेंडेंटल्स पर चूसा। CISC बेहतर है।

@OlofForshell आप कहते हैं, there typically won't be a reminderलेकिन विकी कहते हैं कि mips यह है: en.wikipedia.org/wiki/MIPS_instruction_set#Integer

— एलेक्स

Answer 5

मुझे लगता है कि इस सवाल की गलत धारणा है। यह मुख्य रूप से सिर्फ RISC- जुनूनी शिक्षाविदों है जो x86 को बदसूरत कहते हैं। हकीकत में, x86 ISA एकल निर्देश संचालन में कर सकता है जो RISC ISAs पर 5-6 निर्देश लेगा। RISC के प्रशंसक इस बात का विरोध कर सकते हैं कि आधुनिक x86 सीपीयू इन "जटिल" निर्देशों को माइक्रोफ़ोन में तोड़ देते हैं; तथापि:

1. कई मामलों में यह केवल आंशिक रूप से सच है या बिल्कुल भी सच नहीं है। X86 में सबसे उपयोगी "जटिल" निर्देश कुछ ऐसी चीजें हैं mov %eax, 0x1c(%esp,%edi,4)जैसे कि पता मोड, और ये टूट नहीं रहे हैं।
2. आधुनिक मशीनों पर अक्सर जो अधिक महत्वपूर्ण होता है, वह खर्च किए गए चक्रों की संख्या नहीं होती है (क्योंकि अधिकांश कार्य सीपीयू-बाउंड नहीं होते हैं) लेकिन कोड के अनुदेश कैश प्रभाव। 5-6 निश्चित आकार (आमतौर पर 32 बिट) के निर्देश कैश को एक से अधिक जटिल निर्देशों को प्रभावित करेंगे जो शायद ही कभी 5 बाइट्स से अधिक हो।

x86 ने वास्तव में लगभग 10-15 साल पहले RISC के सभी अच्छे पहलुओं को अवशोषित किया था, और RISC के शेष गुणों (वास्तव में परिभाषित) एक - न्यूनतम निर्देश सेट) को हानिकारक और अवांछनीय है।

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

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

Comments

जहां ऊर्जा की खपत एक शीर्ष चिंता का विषय है, एआरएम या एमआइपी शायद अधिक समझ में आता है ... इसलिए, अगर कम से कम एक पहलू है जहां एआरएम या एमआइपी अधिक समझ में आता है, तो क्या यह जरूरी नहीं है कि x86 सबसे अच्छा आईएसए है?

— शाहबाज

इसलिए मैंने "लागत से अलग ... और उनकी ऊर्जा आवश्यकताओं" के साथ "सर्वश्रेष्ठ" को योग्य बनाया।

— आर .. गिटहब स्टॉप हेल्पिंग आईसीई

मुझे लगता है कि इंटेल सीपीयू की गति को कम कर रहा है, और छोटे मरने के आकार ने बड़े पैमाने पर बिजली के अंतर को समाप्त कर दिया है। 64k L1 और 1MB L2 कैश के साथ नया Celeron डुअल 64-बिट CPU एक 7.5 वाट की चिप है। यह मेरी "स्टारबक्स" हैंगआउट मशीन है, और बैटरी जीवन हास्यास्पद रूप से लंबा है और पी 6 मशीन के चारों ओर रिंग चलाएगा। ज्यादातर फ्लोटिंग पॉइंट कंप्यूटेशन करने वाले एक आदमी के रूप में मैंने बहुत समय पहले RISC को छोड़ दिया था। यह सिर्फ रेंगता है। SPARC विशेष रूप से अत्याचारपूर्ण रूप से हिमनद था। RISC क्यों चूसता है इसका सही उदाहरण Intel i860 CPU था। इंटेल फिर कभी नहीं गया।

@RocketRoy: 7.5 वाट एक डिवाइस के लिए वास्तव में स्वीकार्य नहीं है जो 24/7 संचालित है (और पूरे समय उपयोगी संगणना नहीं कर रहा है) या 3.7v / 2000mAh की बैटरी से चल रहा है।

— R .. गिटहब स्टॉप हेल्पिंग ICE

@RocketRoy "इंटेल i860 सीपीयू। इंटेल फिर कभी नहीं गया।" थोड़ा शोध के बाद, i860 बहुत कुछ लगता है जैसे कि इटेनियम: वीएलआईडब्ल्यू, संकलक-निर्देश अनुदेश समानता ....

— जोनाथन रेनहार्ट

Answer 6

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

16-बिट मोड में, उदाहरण के लिए, संबोधित करना बिल्कुल विचित्र लग सकता है; के लिए एक पता मोड है [BX+SI], लेकिन एक के लिए नहीं [AX+BX]। उस तरह की चीजें जो रजिस्टर उपयोग को जटिल बनाती हैं, क्योंकि आपको एक रजिस्टर में अपने मूल्य को सुनिश्चित करने की आवश्यकता होती है, जिसे आप आवश्यकतानुसार उपयोग कर सकते हैं।

(सौभाग्य से, 32-बिट मोड बहुत अधिक हिरण है (हालांकि अभी भी थोड़ा अजीब है - उदाहरण के लिए विभाजन), और 16-बिट x86 कोड बूट लोडर और कुछ एम्बेडेड वातावरण के बाहर अब काफी हद तक अप्रासंगिक है।)

पुराने दिनों से भी बचा हुआ है, जब इंटेल x86 को परम प्रोसेसर बनाने की कोशिश कर रहा था। कुछ बाइट्स का निर्देश दिया जो लंबे समय तक कार्य करते रहे जो वास्तव में कोई और नहीं करता है, क्योंकि वे स्पष्ट रूप से बहुत धीमी या जटिल थे। ENTER और LOOP निर्देश , दो उदाहरणों के लिए - ध्यान दें कि C स्टैक फ्रेम कोड "पुश एबप; मू ईब, एस्प" और अधिकांश कंपाइलरों के लिए "एंटर" नहीं है।

Comments

मेरा मानना ​​है कि "एंटर" बनाम "पुश / मूव" मुद्दा इसलिए उठा क्योंकि कुछ प्रोसेसरों पर "पुश / मूव" तेज है। कुछ प्रोसेसर पर, "दर्ज करें" तेज है। C'est la vie।

— डिट्रिच एप्प

जब मुझे एक x86 आधारित मशीन के लिए मजबूर किया गया और उस पर एक नज़र रखना शुरू कर दिया (m68k पृष्ठभूमि होने पर), मुझे asm प्रोग्रामिंग निराशाजनक लगने लगी, ... जैसे कि मैंने C जैसी भाषा के साथ प्रोग्रामिंग सीखी है, और फिर हो asm के संपर्क में आने के लिए मजबूर ... आप "महसूस" करते हैं आप अभिव्यक्ति की शक्ति खो देते हैं, सहजता, स्पष्टता, "सुसंगतता", "अंतर्ज्ञानशीलता"। मुझे यकीन है कि अगर मैंने x86 के साथ asm प्रोग्रामिंग शुरू की होगी, तो मुझे लगा होगा यह इतना बुरा नहीं है ... हो सकता है ... मैंने MMIX और MIPS भी किया, और उनका "asm lang" x86 से कहीं बेहतर है (यदि यह Q के लिए सही PoV है, लेकिन शायद यह नहीं है)

— ShinTakezou

एड्रेसिंग मोड की समस्या को 80386 में ठीक किया गया था। केवल 16 बिट कोड में सीमित एड्रेसिंग मोड हैं, 32 बिट कोड बहुत बेहतर है। आप एक विशेष उपसर्ग और इसके विपरीत का उपयोग करके 16 बिट कोड में 32 बिट एड्रेसिंग मोड प्राप्त कर सकते हैं।

— fuz

@FUZxxl: हाँ ... मुझे शायद यह उल्लेख करना चाहिए कि बदसूरती ज्यादातर 16-बिट कोड तक सीमित है। निश्चित (मुझे लगता है)। :)

— cHao

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

— फज

Answer 7

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

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

मैंने एनवीडिया से सुना है कि इंटेल की गलतियों में से एक यह था कि उन्होंने बाइनरी स्वरूपों को हार्डवेयर के करीब रखा था। CUDA का पीटीएक्स कुछ फास्ट रजिस्टर गणना (ग्राफ़िकल कलरिंग) का उपयोग करता है, इसलिए एनवीडिया स्टैक मशीन के बजाय रजिस्टर मशीन का उपयोग कर सकता है, लेकिन अभी भी एक अपग्रेड पथ है जो सभी पुराने सॉफ़्टवेयर को नहीं तोड़ता है।

Comments

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

— डायट्रिच एप्प

@ डिएट्रिच एप: यह पूरी तरह सच नहीं है। X86-64 में ISA में अधिक रजिस्टर दिखाई देते हैं, लेकिन आधुनिक x86 कार्यान्वयन में आमतौर पर एक RISC शैली रजिस्टर फ़ाइल होती है, जिसे क्रियान्वयन में तेजी लाने की मांग पर ISA के रजिस्टर में मैप किया जाता है।

— बिली ओनेल

"मैंने एनवीडिया से सुना है कि इंटेल की गलतियों में से एक यह था कि उन्होंने बाइनरी स्वरूपों को हार्डवेयर के करीब रखा था।" - मुझे यह और CUDA का PTX हिस्सा नहीं मिला।

— पंजे

@ डिट्रेक एप: "और ज्यादातर x86 चिप्स पर निर्देश कैश होने से पहले ही डिकोड हो जाते हैं, उसके बाद नहीं" यह सच नहीं है। उन्हें डिकोड किए जाने से पहले उन्हें कैश किया जाता है। मेरा मानना ​​है कि पेंटियम 4 में एक अतिरिक्त ट्रेस कैश था जो डिकोड के बाद कैश किया गया था, लेकिन इसे बंद कर दिया गया है।

— नाथन फेलमैन

यह सच नहीं है, नवीनतम "रेतीले पुल" प्रोसेसर एक तरह का ट्रेस कैश (जैसे कि पेंटियम 4, ओह उस बूढ़े लड़के: डी) के लिए उपयोग करते हैं, इसलिए प्रौद्योगिकियां चली जाती हैं और वापस आती हैं ...

— क्वोंक्स

Answer 8

उन कारणों के अलावा जिनका लोग पहले ही उल्लेख कर चुके हैं:

• x86-16 में एक अजीब तरह की मेमोरी एड्रेसिंग स्कीम थी जिसमें 4096 तक अलग-अलग तरीकों से एक ही मेमोरी लोकेशन को संबोधित करने की अनुमति दी गई थी, रैम को 1 एमबी तक सीमित किया गया था, और प्रोग्रामर को दो अलग-अलग आकार के पॉइंटर्स से निपटने के लिए मजबूर किया था। सौभाग्य से, 32-बिट के लिए कदम ने इस सुविधा को अनावश्यक बना दिया, लेकिन x86 चिप्स अभी भी खंड रजिस्टरों के cruft को ले जाते हैं।
• जबकि नहीं की एक गलती 86 से प्रति , 86 बुला सम्मेलनों MIPS तरह का मानकीकरण नहीं किया गया था (ज्यादातर क्योंकि MS-DOS किसी भी compilers के साथ नहीं आया था), की गंदगी के साथ हमें छोड़ रहा है __cdecl, __stdcall, __fastcall, आदि

Comments

हम्म .. जब मैं x86 प्रतियोगियों के बारे में सोचता हूं, तो मैं MIPS के बारे में नहीं सोचता। एआरएम या पावरपीसी शायद ....

— बिली ओनेल

@ बिली: x86 लगभग हमेशा के लिए रहा है। एक समय MIPS एक x86 प्रतियोगी था। जैसा कि मुझे याद है कि x86 ने अपने काम को उस स्तर तक पहुंचाने के लिए काटा था जहां वह MIPS के साथ प्रतिस्पर्धात्मक था। (जब MIPS और SPARC वर्कस्टेशन के क्षेत्र में इसे लड़ रहे थे।)

— शैनन सेवेंस

@ शैनॉन सेवरेंस: सिर्फ इसलिए कि एक बार कुछ का मतलब यह नहीं है कि वह कुछ है।

— बिली ओनली

@ सुपरकैट: फ्लैट x86-32 मेमोरी मॉडल के युग में लोग क्या भूल जाते हैं कि 16 बिट्स का मतलब 64k मेमोरी (जो कोई भी गणित को परेशान करता है वह समझ जाएगा कि जादू संभव नहीं है, कि 8086 एक नहीं था अनसुने प्रोग्रामर के लिए बुरा दंड)। लगभग 64k पाने के कुछ तरीके हैं लेकिन 8086 समाधान एक अच्छा समझौता था।

— ओलोफ फोर्सशेल

@ ऑलफोर्सशेल: मुझे लगता है कि कई लोगों ने इस तथ्य को गलत बताया कि 8086 68000 (जो 16MB रैखिक पता करने की जगह और 4 gigs के लिए एक स्पष्ट पथ) के रूप में अच्छा नहीं था। निश्चित रूप से 32-बिट प्रोसेसर पर जाने से 64K से अधिक का उपयोग करना आसान हो जाएगा, लेकिन 8086 एक 16-बिट आर्किटेक्चर है जिसे 8-बिट 8080 से एक कदम ऊपर बनाया गया था। मुझे लगता है कि कोई कारण नहीं है कि इंटेल को लीप होना चाहिए सीधे 8-बिट से 32-बिट तक।

— सुपरकैट

Answer 9

मुझे लगता है कि यदि आप कभी x86 को लक्षित करने वाले कंपाइलर को लिखने का प्रयास करते हैं, या यदि आप x86 मशीन एमुलेटर लिखते हैं, या यहां तक ​​कि यदि आप एक हार्डवेयर डिज़ाइन में ISA को लागू करने का प्रयास करते हैं, तो आपको जवाब का हिस्सा मिलेगा।

हालांकि मैं समझता हूं कि "x86 बदसूरत है!" तर्क, मुझे अभी भी लगता है कि यह अधिक मजेदार है MIPS की तुलना में x86 असेंबली लिखने में (उदाहरण के लिए) - बाद वाला सिर्फ सादा थकाऊ है। यह हमेशा मनुष्यों के बजाय संकलक के लिए अच्छा होना था। मुझे यकीन नहीं है कि एक चिप संकलक लेखकों के लिए अधिक शत्रुतापूर्ण हो सकती है अगर यह कोशिश की ...

मेरे लिए सबसे खराब हिस्सा रास्ता (वास्तविक-मोड) विभाजन काम करता है - कि किसी भी भौतिक पते में 4096 खंड है: ऑफसेट उपनाम। आखिरी बार आपको कब जरूरत पड़ी थी ? अगर खंड भाग 32-बिट पते के कड़ाई से उच्च-क्रम बिट्स होते तो चीजें बहुत सरल होतीं।

Comments

m68k एक बहुत ही मजेदार, और x86 की तुलना में कहीं अधिक मनुष्यों के लिए अच्छा है (जो कि कई m68k प्रोग्रामर के लिए "मानव" नहीं लग सकता है), अगर सही PoV है जिस तरह से मानव उन विधानसभा में कोड लिख सकता है।

— शिनटेकज़ू

सेगमेंट: ऑफ़सेट एड्रेसिंग सीपी / एम - दुनिया के साथ कुछ हद तक संगत रहने का प्रयास था। अब तक के सबसे खराब फैसलों में से एक।

— ट्यूरिंग

@ पूरा करने वाला: खंड: ऑफसेट मुख्य रूप से सीपी / एम दुनिया के साथ संगत रहने का प्रयास नहीं था। 16 बिट प्रोसेसर को विभिन्न खंडों में कोड, डेटा, स्टैक और अन्य मेमोरी क्षेत्रों को रखकर 64 से अधिक केबीटी को संबोधित करने की अनुमति देने के लिए यह एक बहुत ही सफल प्रयास था।

— ओलफ फोर्शेल

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

— आर .. गिटहब स्टॉप मदद ICE

@ बियर: थ्रेड-लोकल स्टोरेज के लिए एफएस / जीएस को चुना गया, ऐसा नहीं है कि इसके लिए सेगमेंट रजिस्टर अच्छे हैं। यह सिर्फ इतना है कि x86 गंभीरता से रजिस्टरों के लिए भूखा है, और सेगमेंट रजिस्टर अप्रयुक्त थे। थ्रेड संरचना की ओर इशारा करने वाला एक सामान्य-उद्देश्य वाला रजिस्टर भी काम करता होगा, और वास्तव में कई रजिस्टरों वाली RISC प्रणालियां एक थ्रेड पॉइंटर के रूप में उपयोग होती हैं।

— R .. गिटहब स्टॉप हेल्पिंग ICE

Answer 10

1. x86 में सामान्य प्रयोजन रजिस्टरों का एक बहुत ही सीमित सेट है

2. यह एक कुशल लोड / स्टोर पद्धति के बजाय न्यूनतम स्तर (CISC नरक) पर विकास की एक बहुत ही अक्षम शैली को बढ़ावा देता है

3. इंटेल ने स्पष्ट रूप से बेवकूफ खंड / ऑफसेट - मेमोरी एड्रेसिंग मॉडल को पेश करने के लिए भयानक निर्णय लिया (इस समय पहले से ही) पुरानी तकनीक के साथ संगत रहने के लिए!

4. एक समय जब हर कोई 32 बिट जा रहा था, x86 ने मुख्यधारा पीसी दुनिया को 16 बिट (उनमें से ज्यादातर - 8088 - यहां तक ​​कि केवल 8 बिट बाहरी डेटा पथों के साथ, जो कि और भी डरावना है!) धारण करके वापस ले लिया।

---

मेरे लिए (और मैं एक डॉस वयोवृद्ध हूं जिसने पीसी के प्रत्येक पीढ़ी को डेवलपर्स के नजरिए से देखा है!) बिंदु 3. सबसे खराब था।

90 के दशक की शुरुआत (मुख्यधारा!) में निम्नलिखित स्थिति की कल्पना करें:

क) एक ऑपरेटिंग सिस्टम जिसमें विरासत कारणों (आसानी से सुलभ रैम की 640kB) के लिए पागल सीमाएं थीं - डॉस

बी) एक ऑपरेटिंग सिस्टम एक्सटेंशन (विंडोज) जो रैम के संदर्भ में अधिक कर सकता है, लेकिन जब यह गेम, आदि जैसे सामानों के लिए सीमित था, तो ... और पृथ्वी पर सबसे स्थिर चीज नहीं थी (सौभाग्य से यह बाद में बदल गया, लेकिन मैं 90 के दशक के शुरुआती दिनों की बात करें)

ग) अधिकांश सॉफ्टवेयर अभी भी डॉस थे और हमें विशेष सॉफ्टवेयर के लिए अक्सर बूट डिस्क बनाना पड़ता था, क्योंकि यह EMM386.exe था जो कुछ कार्यक्रमों को पसंद करते थे, अन्य लोग नफरत करते थे (विशेषकर गेमर्स - और मैं इस समय एक एवीडी गेमर था - मुझे क्या पता है यहाँ बात कर रहा हूँ)

घ) हम एमसीजीए 320x200x8 बिट्स तक सीमित थे (ठीक है, विशेष चाल के साथ थोड़ा और अधिक था, 360x480x8 संभव था, लेकिन केवल रनटाइम लाइब्रेरी समर्थन के बिना), बाकी सब गड़बड़ और भयानक था ("वीईएसए - लोल)"

ई) लेकिन हार्डवेयर के संदर्भ में हमारे पास ३२ बिट मशीनें थीं जिनमें से कुछ मेगाबाइट्स रैम और वीजीए कार्ड के साथ १०२४ up६ up६ to तक का समर्थन था।

इस बुरी स्थिति का कारण?

इंटेल द्वारा एक साधारण डिजाइन निर्णय। मशीन निर्देश स्तर (द्विआधारी स्तर नहीं!) जो पहले से ही मर रहा था, उसके लिए संगतता, मुझे लगता है कि यह 8085 था। अन्य, प्रतीत होता है असंबंधित समस्याएं (ग्राफिक मोड, आदि ...) तकनीकी कारणों से संबंधित थीं और बहुत संकीर्ण होने के कारण दिमाग वास्तुकला x86 मंच खुद के साथ लाया।

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

Comments

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

— 1

@ सुपरकैट: वास्तव में, ईएस रजिस्टर उन स्ट्रिंग निर्देशों से संबंधित कुछ के लिए समर्पित था, जिन्हें स्टोर करने की आवश्यकता होती है (movs, stos) या स्कैनिंग (cmps और scas)। हर खंड रजिस्टर से 64KiB पते को देखते हुए कोड, डेटा और स्टैक मेमोरी (सीएस, डीएस, एसएस) के अलावा अन्य मेमोरी को "लापता लिंक" प्रदान किया गया। सेगमेंट रजिस्टरों ने एक प्रकार की मेमोरी प्रोटेक्शन स्कीम प्रदान की है जिसमें आप रजिस्टरों के 64 केबी मेमोरी ब्लॉक के बाहर पता नहीं लगा सकते हैं। X86 एक 16-बिट आर्किटेक्चर और दिन की लिथोग्राफी की कमी के कारण आपने क्या बेहतर प्रस्ताव दिया?

— ऑलोफ फोर्शेल

@OlofForshell: ES का उपयोग स्ट्रिंग निर्देशों के लिए किया गया था, लेकिन उनका उपयोग न करने वाले कोड के लिए एक अनकमिज़्ड रजिस्टर के रूप में इस्तेमाल किया जा सकता है। बहुत अधिक opcode स्थान की आवश्यकता के बिना seg-reg अड़चन को कम करने का एक तरीका "rseg" उपसर्ग होगा जो यह निर्दिष्ट करेगा कि निम्नलिखित r / m- प्रारूप निर्देश के लिए "r" फ़ील्ड CS / SS / DS से चयन करेगी। / ES / एफएस / जी एस / ?? / ?? AX / BX / CX / DX / SI / DI / SP / BP के बजाय, और FS / GS के लिए उपसर्ग और LFS और LGS (LDS और LES जैसे) के लिए निर्देश हैं। मुझे नहीं पता कि 8086 के लिए सूक्ष्म वास्तुकला कैसे रखी गई थी, लेकिन मुझे लगता है कि ऐसा कुछ काम कर सकता है।

— सुपरकैट

@supercat: जैसा कि मैंने लिखा है, "रजिस्टर एस भी स्मृति के अलावा अन्य लापता लिंक प्रदान करता है ..." एफएस और जीएस 386 तक नहीं पहुंचे थे जैसा कि मुझे याद है।

— Olof Forshell

@ ऑलोफोर्सशेल: उन्होंने ऐसा नहीं किया, जिसने 80286 वास्तुकला को सबसे अधिक संबंध में 8086 वास्तुकला से भी बदतर बना दिया। मेरा कहना था कि कुछ और सेगमेंट रजिस्टर (या उस मामले के लिए भी एक) को जोड़कर 8086 आर्किटेक्चर को बहुत अधिक उपयोगी बना दिया गया होगा, और निर्देश सेट क्लीनर और अधिक उपयोगी हो सकता था यदि सेगमेंट रजिस्टर को बहुत अधिक एक्सेस किया जा सकता है। अन्य।

— सुपरकैट