सीपीयू डिजाइन को कैसे प्रभावित किया है? [बन्द है]

Question

हमें अक्सर बताया जाता है कि हार्डवेयर को इस बात की परवाह नहीं है कि कोई प्रोग्राम किस भाषा में लिखा गया है क्योंकि यह केवल संकलित बाइनरी कोड को देखता है, हालांकि यह पूरी सच्चाई नहीं है। उदाहरण के लिए, विनम्र Z80 पर विचार करें; 8080 इंस्ट्रक्शन सेट के लिए इसके एक्सटेंशन में CPIR जैसे निर्देश शामिल हैं जो C- स्टाइल (NULL-टर्मिनेटेड) स्ट्रिंग्स को स्कैन करने के लिए उपयोगी है, उदाहरण के लिए strlen()। डिजाइनरों ने पहचान लिया होगा कि चल रहे सी प्रोग्राम (पास्कल के विपरीत, जहां एक स्ट्रिंग की लंबाई हेडर में है) कुछ ऐसा था कि उनके डिजाइन का उपयोग करने की संभावना थी। एक और क्लासिक उदाहरण लिस्प मशीन है ।

और क्या उदाहरण हैं? जैसे निर्देश, संख्या और रजिस्टर के प्रकार , संबोधित करने के तरीके, जो किसी विशेष प्रोसेसर को किसी विशेष भाषा के सम्मेलनों के पक्ष में बनाते हैं? मैं विशेष रूप से एक ही परिवार के संशोधनों में दिलचस्पी रखता हूं।

Comments

यह मत भूलो कि Z-80 में एलडीआईआर निर्देश भी था, जब आप लंबाई जानते हैं तो बहुत उपयोगी होते हैं, जब आप लंबाई जानते हैं (जैसे पास्कल, जहां लंबाई हेडर में संग्रहीत होती है)।

— TMN

1. Z-80 को 1975 में डिजाइन किया गया था, जब K & R के पहले संस्करण से 3 साल पहले यूनिक्स और C कुछ कंप्यूटरों पर एक अस्पष्ट ऑपरेटिंग सिस्टम और भाषा थे। 2. पास्कल के बारे में कुछ भी नहीं है जो स्ट्रिंग की लंबाई को "हेडर में" बताता है। 3. सीपी / एम में स्ट्रिंग्स, उस समय के प्रमुख माइक्रो कंप्यूटर, को '$' वर्ण के साथ समाप्त किया गया था, न कि '0' 0। CPIR किसी भी पात्र को खोज सकता है। 4. CPIR का CPDR (खोज पीछे की ओर), साथ ही अन्य -IR और -DR निर्देशों के साथ मिलान किया जाता है। निष्कर्ष: CPIR का C प्रोग्रामिंग लैंग्वेज से कोई लेना-देना नहीं है। यह सिर्फ एक बाइट खोज निर्देश है।

— कामवासना

सी द्वारा मजबूर चीजों के सबसे बड़े (और हार्डवेयर डिजाइनरों के लिए सबसे अधिक परेशान) एक बाइट एड्रेसिंग है। इस घृणा के बिना सीपीयू सरल और तेज होता।

— SK-लॉजिक

@ SK- तर्क: हालांकि POSIX मानक को बाइट एड्रेसिंग की आवश्यकता होती है, सी मानक नहीं है। किसी भी कार्यान्वयन जहां sizeof(int)1 के बराबर होना चाहिए उस प्रकार charपर हस्ताक्षर किए जाने intचाहिए (चूंकि सभी प्रकार के मूल्यों को धारण करने में सक्षम होना चाहिए char)। मैं एक मशीन के लिए कोड लिखा जहां गए हैं charऔर intदोनों 16-बिट पर हस्ताक्षर किए पूर्णांक हैं; सबसे बड़ी कठिनाइयाँ यह हैं कि एक प्रकार के रूपांतरण के लिए यूनियनों का उपयोग नहीं किया जा सकता है, और बड़ी संख्या में बाइट्स के कुशल भंडारण के लिए मैनुअल पैकिंग और अनपैकिंग की आवश्यकता होती है। सी में आकार की संभावना की तुलना में वे मुद्दे मामूली हैं (int) == sizeof (लंबा), चूंकि ...

— सुपरकैट

... इसका मतलब है कि कोई मानक प्रकार नहीं है जो दो unsigned intमूल्यों के बीच अंतर रखने की गारंटी है । C99 ने उस स्थिति में सुधार किया, लेकिन C99 से पहले प्रकार के मूल्य के लिए संभावित-नकारात्मक मूल्य की तुलना करने के लिए कोई गारंटी-सुरक्षित एकल-चरण तरीका नहीं था unsigned int(किसी को परीक्षण करना होगा कि क्या तुलना करने से पहले संख्या नकारात्मक थी)।

— सुपरकैट

Answer 1

मौजूदा उत्तर आईएसए परिवर्तनों पर केंद्रित हैं। अन्य हार्डवेयर परिवर्तन भी हैं। उदाहरण के लिए, C ++ आमतौर पर वर्चुअल कॉल के लिए vtables का उपयोग करता है। पेंटियम एम के साथ शुरू , इंटेल में एक "अप्रत्यक्ष शाखा भविष्यवक्ता" घटक है जो आभासी फ़ंक्शन कॉल को तेज करता है।

Comments

और बर्कले RISC वास्तुकला में "रजिस्टर फ़ाइल" की अवधारणा शामिल थी, इसलिए स्टैक पर फ़ंक्शन "स्पिल" रजिस्टर बनाने के बजाय, प्रत्येक फ़ंक्शन को 8 रजिस्टरों का एक ब्लॉक दिया गया था। यह ऑब्जेक्ट-ओरिएंटेड कोड को काफी बढ़ा देता है, क्योंकि इसमें कई तरीकों के कॉल से लेकर शॉर्ट मेथड शामिल होते हैं।

— TMN

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

— डेडएमजी

@ डीडीएमजी: अन्य मामलों में फायदा हुआ, यह सच है। लेकिन जब तक C ++ लोकप्रिय नहीं हुआ, तब तक CPU डिज़ाइन प्रभावित नहीं हुए । और वह सवाल था। इसी तरह, TMN में रजिस्टर फाइलों के बारे में एक बिंदु है। विधानसभा में कार्यों की इतनी स्पष्ट अवधारणा नहीं थी। फ़ंक्शंस, जैसा कि हम आमतौर पर उन्हें आज समझते हैं, अल्गोल 60 की तारीख से पहले, और इसलिए हम कह सकते हैं कि अल्गोल 60 ने सीपीयू रजिस्टर फ़ाइल डिज़ाइन को प्रभावित किया।

— एमएसलटर्स

Answer 2

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

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

Comments

इसके लिए भी ENTERप्रतिपक्ष है RET n...

— herby

@herby: मुझे नहीं लगता ENTERकि मूल 8086 में अस्तित्व में था; यह बाद के प्रोसेसर के साथ आया था। यह एक दिलचस्प बिंदु लाता है, हालांकि: बीपी-आधारित एड्रेसिंग मोड स्पष्ट रूप से फ़्रेम पॉइंटर के माध्यम से एक्सेस किए गए स्टैक्ड मापदंडों और स्थानीय लोगों के उपयोग के आसपास डिज़ाइन किए गए हैं। मुझे यह सम्मेलन कई तरीकों से दिलचस्प लगता है, विशेष रूप से यह देखते हुए कि (1) शुद्ध विधानसभा भाषा कोड स्टैक की तुलना में रजिस्टरों में मूल्यों का उपयोग करने के लिए अधिक उपयुक्त है, लेकिन [बीपी + एनएन] के फायदे [2] को संबोधित करते हुए [एसपी +] nn] असेंबली-भाषा के कार्यक्रमों के लिए और अधिक महत्वपूर्ण हैं जो स्टैक पर चीजों को एक्सेस करते हैं ...

— सुपरकैट

... हाथ से लिखे विधानसभा कोड के लिए। एक संकलक आमतौर पर हर उत्पन्न निर्देश के लिए, एसपी और बीपी की तुलना कैसे करेगा; उदाहरण के लिए यदि SP BP-8 है, तो संकलक के लिए [SP + 20] की तुलना में [BP + 12] को संबोधित करना वास्तव में आसान नहीं है। यदि कंपकंपी पर कंपाइलर को कोड के एक ब्लॉक के चारों ओर एक और PUSH / POP जोड़ना पड़ता है, तो यह SP- आधारित ऑफ़सेट को उचित रूप से समायोजित कर सकता है। दूसरी ओर, हाथ से लिखी विधानसभा में, PUSH / POP जोड़ने से अधिक संभावना है कि उनके बीच कोड को ट्विक करने की आवश्यकता होगी। तो फ़्रेम पॉइंटर्स मुख्य रूप से संयुक्त उच्च-स्तरीय / एएसएम कोड का लाभ है।

— सुपरकैट

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

— 14

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

— सुपरकैट

Answer 3

एक उदाहरण MIPS है, जो दोनों है addऔर adduफँसाने और क्रमशः अतिप्रवाह अनदेखी के लिए। (इसके अलावा subऔर subu।) यह एडीए जैसी भाषाओं के लिए अनुदेश का पहला प्रकार की जरूरत (मुझे लगता है कि - मैं वास्तव में कभी एडीए हालांकि प्रयुक्त) स्पष्ट रूप से अतिप्रवाह और सी जैसी भाषाओं कि अतिप्रवाह की अनदेखी के लिए दूसरे प्रकार के साथ जो सौदा।

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

Comments

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

— NikiC

@ नाइक: मैं सोच रहा था कि निर्देश adduऔर subu( ओवरफ्लो की जांच न करने वाले) सी खुश करने के लिए जोड़े गए थे। बेशक, मैं वास्तव में नहीं जानता - हमने केवल इसे व्याख्यान में कवर किया है और मैं निश्चित रूप से वास्तुकला में कोई विशेषज्ञ नहीं हूं: पी।

— तिखन जेल्विस

ओह, मैं दूसरे तरीके से सोच रहा था, क्षमा करें: /

— NikiC

Answer 4

बर्रोज़ 5000 श्रृंखला को कुशलतापूर्वक ALGOL का समर्थन करने के लिए डिज़ाइन किया गया था, और Intel के iAPX-432 को Ada को कुशलतापूर्वक निष्पादित करने के लिए डिज़ाइन किया गया था। इनमोस ट्रांसप्यूटर की अपनी भाषा थी, ओकाम। मुझे लगता है कि Parallax "Propeller" प्रोसेसर को BASIC के अपने स्वयं के संस्करण का उपयोग करके प्रोग्राम करने के लिए डिज़ाइन किया गया था।

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

Comments

इन डिज़ाइनों के बारे में ऐसा क्या है जो उन्हें विशेष रूप से उपयुक्त बनाता है? उदाहरण के लिए, IAPX की किस विशेषता से विशेष रूप से Ada को फायदा होता है?

— गयूस

ISTR कि iAPX-432 का एडीए लक्ष्य एक असफल डिजाइन को बचाने की कोशिश कर रहा था, इसे किसी और चीज की तुलना में अभी तक बड़ी उम्मीदों के साथ संलग्न करके।

— एपीग्रामग्राम

@AProgrammer: मुझे पूरा यकीन है कि iAPX-432 को Ada का उपयोग करने के लिए शुरू से डिज़ाइन किया गया था। मुझे कुछ अफवाहें भी याद हैं जो इंटेल ने निर्देश सेट को प्रकाशित करने, असेंबली भाषा प्रोग्रामिंग को हतोत्साहित करने और लोगों को हर चीज के लिए एडा का उपयोग करने के लिए मजबूर करने के लिए नहीं किया था।

— TMN

@ टीएमएन, इंटेल की 432 परियोजना 1975 में शुरू हुई और 1981 (विकिपीडिया) में शुरू की गई। आयरनमैन (एडीए के लिए अंतिम आवश्यकताएं), जनवरी 1977 में प्रकाशित किया गया था, और हरे रंग को मई 1979 में चुना गया था, संशोधित किया गया और अंतिम परिणाम जुलाई 1980 में एक सैन्य मानक के रूप में प्रकाशित किया गया था। यह बताते हुए कि आईएपीएक्स -432 डिज़ाइन किया गया था, में एक समयरेखा मुद्दा है। Ada का उपयोग करने के लिए शुरुआत। (यह एक देर से और विशिष्ट "सिमेंटिक गैप को बंद करें" प्रोसेसर है जो सामान्य कमियों के साथ एक समय पर विकल्प खोजा जा सकता है। इसे Ada प्रोसेसर के रूप में विपणन करना एक असफल डिजाइन को बचाने के लिए एक अस्थायी था - ISTR कि कोई भी नहीं लेकिन इंटेल ने इसका इस्तेमाल किया था; )

— एपीग्रामग्राम

@APgramgram: हम्म, लगता है कि आप सही हैं। मैं 432 के मुख्य वास्तुकार से इस पत्र के पार चला गया और सारांश में वह कहता है "वास्तुकला और भाषा का यह घनिष्ठ मेल नहीं हुआ क्योंकि 432 को एडा को निष्पादित करने के लिए डिज़ाइन किया गया था- यह नहीं था।" मुझे अपनी पुरानी 432 पुस्तक को खोदना होगा और देखना होगा कि यह क्या कहती है।

— टीएमएन

Answer 5

एक बात जिसका उल्लेख अब तक किसी ने नहीं किया है वह यह है कि कंपाइलर ऑप्टिमाइज़ेशन (जहां आधार भाषा काफी हद तक अप्रासंगिक है) में आगे बढ़ना CISC इंस्ट्रक्शन सेट्स (जो कि बड़े पैमाने पर मनुष्यों द्वारा कोडित किया गया था) से RISC इंस्ट्रक्शंस सेटों में स्थानांतरित कर दिया गया (जो काफी हद तक थे) संकलक द्वारा कोड किए जाने के लिए डिज़ाइन किया गया है।)

Answer 6

मोटोरोला 68000 परिवार ने कुछ ऑटोइन्क्रिमेंट एड्रेसमोड की शुरुआत की, जो कि सीपीयू के माध्यम से प्रतिलिपि डेटा को बहुत कुशल और कॉम्पैक्ट बनाते हैं।

[अद्यतित उदाहरण]

यह कुछ c ++ कोड था जिसने 68000 कोडांतरक को प्रभावित किया था

while(someCondition)
    destination[destinationOffset++] = source[sourceOffset++]

पारंपरिक असेंबलर में लागू (pseudocode, मैं 68000 कोडांतरक आदेशों को भूल गया)

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1)
    move (adressRegister2), akku
    increment(adressRegister1, 1)
    increment(adressRegister2, 1)
}

नए adressmode के साथ यह कुछ simmilar बन गया

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1++)
    move (adressRegister2++), akku
}

4 के बजाय प्रति लूप केवल दो निर्देश।

Comments

यह एक विशेष भाषा के सम्मेलनों से कैसे प्रभावित हुआ?

— गयूस

अपडेटेड उदाहरण देखें

— k3b

आह, मुझे DBxx पाश अनुकूलन के 68010. में याद दिलाता है

— गयुस

वास्तव में, मुझे लगता है कि आपके पास यह पीछे है। ऑटो [में | de] क्रीमेंट संबोधन PDP-11 निर्देश सेट का हिस्सा था, जिसने संभवतः

— TMN

Answer 7

IBM की Z सीरीज़ मेनफ्रेम, 1960 के दशक से IBM 360 की वंशज है।

कई निर्देश थे जो विशेष रूप से COBOL और फोरट्रान कार्यक्रमों को गति देने के लिए वहां रखे गए थे। क्लासिक उदाहरण है BXLE- "इंडेक्स कम या समान पर शाखा" जो कि एक फोरट्रान forलूप या COBOL PERFORM VARYING x from 1 by 1 until x > nमें से अधिकांश एक ही निर्देश में समझाया गया है।

COBOL कार्यक्रमों में फिक्स्ड पॉइंट दशमलव अंकगणितीय आम का समर्थन करने के लिए पैक्ड दशमलव निर्देशों का एक पूरा परिवार भी है।

Comments

मुझे लगता है तुम्हारा मतलब वंशज है ।

— क्लॉकवर्क-म्यूजियम

@ एक्स-जीरो - उफ़! सुबह जल्दी, सिस्टम में पर्याप्त कैफीन नहीं आदि .......

— जेम्स एंडरसन

अधिक दिलचस्प टीआई 32050 डीएसपी का ब्लॉक-रिपीट निर्देश है। इसका ऑपरेंड लूप में पिछले एक के बाद अनुदेश का पता है; लूप-काउंट रजिस्टर को लोड करना और फिर ब्लॉक-रिपीट निर्देश को निष्पादित करने से निर्धारित समय तक निर्दिष्ट किए जाने वाले लक्ष्य तक (लेकिन शामिल नहीं) तक निर्देश मिलेंगे। बहुत जोरदार एक फोरट्रान DOलूप की याद दिलाता है ।

— सुपरकैट

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

— जॉन आर। स्ट्रोह्म

@ JohnR.Strohm: मेरे द्वारा देखे गए प्रत्येक डीएसपी में एक दोहराव-गुणा-संचय शामिल है, लेकिन उन सभी में अधिक सामान्यीकृत शून्य-ओवरहेड लूप शामिल नहीं हैं। वास्तव में, मुझे पूरा यकीन नहीं है कि इस तरह के छोरों को केवल "डीएसपी" फीचर माना जाना चाहिए, क्योंकि वे बहुत सारे "पारंपरिक प्रोसेसर" कोड में भी उपयोगी होंगे।

— सुपरकैट

Answer 8

प्रारंभिक इंटेल सीपीयू में निम्नलिखित विशेषताएं थीं, उनमें से कई अब 64-बिट मोड में आबंटित हैं:

• ENTER, LEAVE और RET nn निर्देश [प्रारंभिक मैनुअल ने स्पष्ट रूप से बताया कि उन्हें ब्लॉक संरचित भाषाओं, उदाहरण के लिए, पास्कल के लिए पेश किया गया था, जो नेस्टेड प्रक्रियाओं का समर्थन करता है]
• बीसीडी अंकगणित (एएए, एएएम, आदि) को गति देने के निर्देश; x87 में भी BCD का समर्थन
• JCXZ और LOOP को गिने हुए लूप को लागू करने के निर्देश
• INTO, अंकगणितीय अतिप्रवाह पर एक जाल बनाने के लिए (जैसे, Ada में)
• तालिका देखने के लिए XLAT
• सरणी सीमा की जाँच के लिए आधार

कई सीपीयू के स्टेटस रजिस्टर में पाया गया साइन फ्लैग आसानी से हस्ताक्षरित और अहस्ताक्षरित अंकगणित करने के लिए मौजूद है।

एसएसई 4.1 निर्देश सेट में स्ट्रिंग प्रसंस्करण, दोनों गिने और शून्य-टर्मिनेटेड (PCMPESTR, आदि) के लिए निर्देश दिए गए हैं।

इसके अलावा, मैं कल्पना कर सकता था कि संकलित कोड (सेगमेंट लिमिट की जाँच, पैरामीटर कॉपी के साथ कॉल गेट्स, आदि) की सुरक्षा का समर्थन करने के लिए कई सिस्टम-स्तरीय विशेषताओं को डिज़ाइन किया गया था।

Answer 9

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

ऐसी इकाई वाले प्रोसेसर में BXJ इंस्ट्रक्शन शामिल होता है, जो प्रोसेसर को विशेष "Jazelle मोड" में डालता है, या यदि यूनिट को सक्रिय करना विफल हो गया था, तो इसे केवल सामान्य शाखा निर्देश के रूप में व्याख्या किया जाता है। इकाई JVM राज्य धारण करने के लिए एआरएम रजिस्टरों का पुन: उपयोग करती है।

जज़ले तकनीक का उत्तराधिकारी थम्बेई है

Answer 10

जहां तक ​​मुझे पता है कि यह अतीत में अधिक सामान्य था।

प्रश्नों का एक सत्र है है जिसमें जेम्स गोस्लिंग ने कहा था कि ऐसे लोग हार्डवेयर बनाने की कोशिश कर रहे हैं जो JVM बाइटेकोड के साथ बेहतर व्यवहार कर सकते हैं, लेकिन तब ये लोग इसे सामान्य "सामान्य" इंटेल x86 के साथ करने का एक तरीका खोज लेंगे (हो सकता है कुछ चतुर तरीके से बाइटकोड)।

उन्होंने उल्लेख किया कि जेनेरिक लोकप्रिय चिप (जैसे इंटेल) का उपयोग करने में लाभ है, क्योंकि इसमें एक बड़ा निगम उत्पाद पर भारी रकम फेंक रहा है।

वीडियो देखने लायक है। वह 19 या 20 मिनट पर इस बारे में बात करता है।

Answer 11

मैंने एक त्वरित पृष्ठ खोज की और ऐसा लगता है कि किसी ने विशेष रूप से फोर्थ को निष्पादित करने के लिए सीपीयू के विकसित होने का उल्लेख नहीं किया है । आगे प्रोग्रामिंग भाषा ढेर, आधारित कॉम्पैक्ट, और नियंत्रण प्रणाली में प्रयोग किया जाता है।

Answer 12

इंटेल iAPX सीपीयू विशेष रूप से OO भाषाओं के लिए डिजाइन किया गया था। हालांकि काफी काम नहीं किया।

IAPX 432 ( इंटेल उन्नत प्रोसेसर आर्किटेक्चर ) इंटेल का पहला 32-बिट माइक्रोप्रोसेसर डिजाइन, तीन एकीकृत परिपथों का एक सेट के रूप में 1981 में पेश किया गया था। यह 1980 के दशक के लिए इंटेल के प्रमुख डिजाइन होने का इरादा था, कई उन्नत मल्टीटास्किंग और मेमोरी प्रबंधन सुविधाओं को लागू करता है। इसलिए डिजाइन को माइक्रोमेनफ्रेम के रूप में संदर्भित किया गया था ...

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

अपने दिन के अर्धचालक प्रौद्योगिकी का उपयोग करते हुए, इंटेल के इंजीनियर डिजाइन को पहले कुशल कार्यान्वयन में बदलने में सक्षम नहीं थे। समय से पहले अडा कंपाइलर में अनुकूलन की कमी के साथ, इसने धीमी गति से लेकिन महंगे कंप्यूटर सिस्टम में योगदान दिया, एक ही घड़ी आवृत्ति (1982 की शुरुआत में) में नई 80286 चिप की गति लगभग 1/4 पर विशिष्ट बेंचमार्क का प्रदर्शन किया।

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

आईएपीएक्स 432 परियोजना इंटेल के लिए एक व्यावसायिक विफलता थी ...

Comments

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

— सुपरकैट

Answer 13

68000 में MOVEM था जो एक ही निर्देश में ढेर पर कई रजिस्टरों को धकेलने के लिए सबसे उपयुक्त था, जो कि कई भाषाओं की उम्मीद थी।

यदि आपने पूरे कोड में JSR (जंप सबरूटीन) से पहले MOVEM (MOVE मल्टीपल) को देखा तो आपको आमतौर पर पता था कि आप C कंप्लाइंड कोड के साथ काम कर रहे थे।

MOVEM ने गंतव्य रजिस्टर के ऑटो वेतन वृद्धि के लिए अनुमति दी, प्रत्येक उपयोग गंतव्य पर स्टैकिंग जारी रखने के लिए, या ऑटो डिक्रीमेंट के मामले में स्टैक को हटाने की अनुमति देता है।

http://68k.hax.com/MOVEM

Answer 14

Atmel का AVR आर्किटेक्चर पूरी तरह से C में प्रोग्रामिंग के लिए उपयुक्त होने के लिए जमीन से डिज़ाइन किया गया है। उदाहरण के लिए, यह एप्लिकेशन नोट आगे विस्तृत करता है।

IMO यह निकटता से संबंधित रॉकेट्स 4kids'es उत्कृष्ट उत्तर के साथ है, प्रारंभिक PIC16-s को सीधे असेंबलर प्रोग्रामिंग (40 निर्देश कुल) के लिए विकसित किया जा रहा है, बाद में सी को लक्षित करने वाले परिवारों के साथ।

Answer 15

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

float a = 16777216, b = 0.125, c = -16777216;
float d = a+b+c;

को बढ़ावा देने के हैं aऔर bकरने के लिए double, उन्हें जोड़ें को बढ़ावा देने cके लिए double, यह जोड़ने के लिए, और उसके बाद की दुकान परिणाम को गोल float। भले ही यह एक संकलक के लिए कई मामलों में तेजी से कोड उत्पन्न करने के लिए होता है जो सीधे प्रकार पर संचालन करेंगे float, यह फ्लोटिंग-पॉइंट रूटीन का एक सेट के लिए सरल था जो केवल प्रकार पर संचालित होगा double, साथ में / में बदलने के लिए रूटीन से float, दिनचर्या के अलग सेट पर कार्रवाई को संभालने के लिए है करने के लिए की तुलना में floatऔर double। 8087 को अंकगणित के लिए उस दृष्टिकोण के आसपास डिजाइन किया गया था, 80-बिट फ्लोटिंग-पॉइंट प्रकार का उपयोग करके सभी अंकगणितीय संचालन का प्रदर्शन किया गया था [80 बिट शायद इसलिए चुना गया था:

1. कई 16- और 32-बिट प्रोसेसर पर, यह 64-बिट मंटिसा के साथ काम करने के लिए तेज़ है और मूल्य के साथ काम करने के लिए एक अलग घातांक है जो मंटिसा और प्रतिपादक के बीच एक बाइट को विभाजित करता है।

2. गणना करना बहुत मुश्किल है जो संख्यात्मक प्रकारों की पूरी सटीकता के लिए सटीक है जो एक का उपयोग कर रहा है; अगर कोई log10 (x) जैसी किसी चीज़ की गणना करने की कोशिश कर रहा है, तो एक परिणाम की गणना करना आसान और तेज़ है, जो कि 80-बिट प्रकार के 100ulp के भीतर सटीक है एक परिणाम की गणना करने के लिए जो 64-बिट के 1ulp के भीतर सटीक है प्रकार, और पूर्व परिणाम को 64-बिट सटीकता के लिए राउंड करने से 64-बिट मान प्राप्त होगा जो बाद के मुकाबले अधिक सटीक है।

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

double f = f1()*f2() - f3()*f4();

निम्न तरीकों में से किसी में:

double f = (float)(f1()*f2()) - (extended_double)f3()*f4();
double f = (extended_double)f1()*f2() - (float)(f3()*f4());
double f = (float)(f1()*f2()) - (float)(f3()*f4());
double f = (extended_double)f1()*f2() - (extended_double)f3()*f4();

ध्यान दें कि यदि f3 और f4 क्रमशः f1 और f2 के समान मान लौटाते हैं, तो मूल अभिव्यक्ति स्पष्ट रूप से शून्य वापस आनी चाहिए, लेकिन बाद के कई भाव नहीं हो सकते। इसके कारण लोगों ने 8087 की "अतिरिक्त परिशुद्धता" की निंदा की, भले ही अंतिम सूत्रीकरण आम तौर पर तीसरे से बेहतर होगा - और कोड के साथ जो उचित रूप से विस्तारित डबल प्रकार का उपयोग करता था - शायद ही कभी हीन होगा।

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

Comments

ध्यान दें कि आपको इस पोस्ट में पहले ही एक उत्तर ( ऊपर ) मिल गया है । क्या वे उत्तर हैं जिन्हें एक में मिलाया जा सकता है / होना चाहिए?

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

— सुपरकैट

केवल निश्चित कर रहा था। व्यक्तिगत रूप से, मुझे विश्वास है कि यह एक, मजबूत उत्तर (वर्गों को अलग करने के लिए हेडर का उपयोग करना) करना संभव होगा, लेकिन इस पर मेरा विचार है। आप अभी भी शीर्षकों को स्पष्ट रूप से पहचानने के लिए उपयोग कर सकते हैं कि प्रत्येक उत्तर भाग के पते क्या हैं ( ## How the stack changed the processorऔर ## How floating point changed the processor) ताकि लोग उसे पढ़ते समय उचित मन सेट कर सकें और यह सोचने की कम संभावना हो कि आप या तो जवाब देने या फिर से पढ़ने में अनुपस्थित थे। समान (r समान) उत्तर।

@MichaelT: दो जवाब पर्याप्त रूप से असंतुष्ट हैं कि मुझे लगता है कि उन्हें अलग से वोट दिया जाना चाहिए। हालांकि 80486 ने 8087/80287/80387 द्वारा पहले किए गए कार्यों को अवशोषित किया, 8086 और 8087 को लगभग स्वतंत्र आर्किटेक्चर के साथ अलग-अलग चिप्स के रूप में डिजाइन किया गया था। यद्यपि दोनों एक सामान्य निर्देश धारा से कोड चलाते थे, जो कि 8086 को कुछ बाइट अनुक्रमों के द्वारा नियंत्रित किया गया था, क्योंकि डेटा बस की अनदेखी करते हुए पता पढ़ने / लिखने के अनुरोधों को उत्पन्न करने के लिए अनुरोध किया गया था, और 8087 में बाकी सब कुछ अनदेखा किया गया था।

— सुपरकैट