एलपी 64, एलएलपी 64 और आईएल 32 संक्रमण

Question

80 के दशक में 16 से 32 बिट के संक्रमण के दौरान, int या तो 16 या 32 बिट था। वर्तमान 64 बिट संक्रमण नामकरण का उपयोग करके, मैं समझता हूं कि आईएलपी 32 और एलपी 32 मशीनों का एक सुंदर भी फैल गया था। उस समय मेरा मानना ​​है कि यह समझा गया था कि int किसी भी दिए गए आर्किटेक्चर के लिए हमेशा रजिस्टर या सूचक चौड़ाई का पालन करेगा और long 32 बिट रहेगा।

फास्ट फॉरवर्ड 25 साल, मुझे लगता है कि एलपी 64 काफी मुख्यधारा है, लेकिन जब तक मुझे 64 बिट प्लेटफ़ॉर्म का सामना नहीं हुआ [2007 में डेस्कटॉप लिनक्स की मेरी खोज :) :), मुझे हमेशा आईपी 64 अगले लॉजिकल चरण होने की उम्मीद थी।

1. क्या यह (एलपी 64) 64 बिट के लिए अपेक्षित विकास था?
   • char <= short <= int <= long संबंध हमारे द्वारा छोड़े गए प्रत्येक प्लेटफॉर्म पर एक पूर्णांक प्रकार को ठीक करने की इस उभरती योजना में कैसे फिट करता है?
   • ये संक्रमण योजनाएं विभिन्न प्लेटफ़ॉर्म पर ({l,u}case की आपकी पसंद) WORD/DWORD के उपयोग से संबंधित कैसे हैं?
   • विंडोज के कुछ क्षेत्रों में अभी भी INT रूप हैं जो 16 बिट हैं। क्या विंडोज एलएलपी 64 से बाहर निकल जाएगा या क्या यह बहुत देर हो चुकी है?
   • 3212 संक्रमण के दौरान इस समय के पीछे छोड़ने के लिए int क्यों छोड़ा गया था?

Answer 1

मैं यह कैसे देख यह है कि Windows पूरे 64 संक्रमण में एक oddball है। लेकिन उस तरफ डालने से, सी या सी ++ ने कभी-कभी अभिन्न प्रकार को निश्चित-लंबाई निर्धारित नहीं किया। मुझे पूरी तरह से int/long/सूचक चीज़ काफी समझा जा सकता है, यदि आप इसे इस तरह देखते हैं:

int: अधिकतर 32 बिट लंबे (लिनक्स, मैक और विंडोज) लंबा: मैक और लिनक्स पर 64 बिट्स, 32 पर विंडोज लंबे: (64-बिट सिस्टम पर 32-बिट पर 32, 64) सूचक की सटीक लंबाई

मैं केवल संदर्भ में चार का उपयोग करें: मैक, लिनक्स, और Windows x64 (यू) intptr_t पर 64-बिट तारों का और कभी भी छोटा उपयोग नहीं करते, क्योंकि यह तब तक अधिकांश डेस्कटॉप सिस्टम पर एक int है।

शब्द और ड्वॉर्ड बदसूरत हैं, और इससे बचा जाना चाहिए। यदि एपीआई आपको उनका उपयोग करने के लिए मजबूर करता है, तो DWORD_PTR के साथ DWORD को प्रतिस्थापित करें जब आप ... से बात कर रहे हैं, पॉइंटर्स। आईएमएचओ के पहले स्थान पर वहां (डी) शब्द का उपयोग करना कभी भी सही नहीं था।

मुझे नहीं लगता कि विंडोज़ इसके निर्णय को कभी भी बदल देगा। बहुत अधिक परेशानी पहले से ही

पीछे क्यों छोड़ा गया था? वीनस विपरीत दिशा में घूमता क्यों है? पहले प्रश्न का उत्तर here (मुझे विश्वास है), दूसरा थोड़ा अधिक जटिल है;)

Answer 2

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

इसी कारण से, short 32-बिट और int 64-बिट बनाने के लिए संभव नहीं होगा: कई चीजों के लिए 16-बिट प्रकार आवश्यक है, ऑडियो प्रोसेसिंग सबसे पहले दिमाग में आता है। (विंडोज़/जावा के बदसूरत यूटीएफ -16 जुनून का जिक्र नहीं है ..)

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