क्रॉस कंपाइलर
| कार्यक्रम निष्पादन |
|---|
| सामान्य अवधारणाएँ |
| कोड के प्रकार |
| संकलन रणनीतियाँ |
| उल्लेखनीय रनटाइम्स |
|
| उल्लेखनीय संकलक और टूलचेन |
|
क्रॉस कंपाइलर एक कंपाइलर होता है, जो प्लेटफॉर्म (कंप्यूटिंग) के लिए निष्पादन योग्य कोड बनाने में सक्षम होता है, जिस पर कंपाइलर चलता है। उदाहरण के लिए कंपाइलर जो एक निजी कंप्यूटर पर चलता है लेकिन कोड उत्पन्न करता है जो एंड्रॉइड ऑपरेटिंग प्रणाली स्मार्टफोन पर चलता है, यह एक क्रॉस कंपाइलर के रूप में होता है।
क्रॉस कंपाइलर, एक डेवलपमेंट होस्ट से एकाधिक प्लेटफॉर्म के लिए कोड को संकलित करने के लिए उपयोगी होते है। लक्ष्य प्लेटफॉर्म पर प्रत्यक्ष कंपाइलिंग अव्यावहारिक रूप में होता है, उदाहरण के लिए एम्बेडेड प्रणाली पर सीमित कंप्यूटिंग संसाधनों के साथ.उपयोगी होता है।
क्रॉस कंपाइलर्स स्रोत से स्रोत कंपाइलर के लिए भिन्न रूप में होते है। क्रॉस कंपाइलर, मशीन कोड के क्रॉस-प्लेटफ़ॉर्म सॉफ़्टवेयर उत्पादन के लिए होता है, जबकि स्रोत-से-स्रोत कंपाइलर, टेक्स्ट कोड में कोडिंग लैंग्वेज का दूसरी लैंग्वेज में अनुवाद करता है। दोनों प्रोग्रामिंग उपकरण हैं।
प्रयोग
क्रॉस कंपाइलर का मौलिक उपयोग निर्माण वातावरण को लक्षित वातावरण से भिन्न करना है। यह कई स्थितियों में उपयोगी है
- एम्बेडेड प्रणाली जहां उपकरण में अत्यधिक सीमित संसाधन होते हैं। उदाहरण के लिए, एक माइक्रोवेव ओवन में अपने कीपैड और डोर सेंसर को पढ़ने, डिजिटल डिस्प्ले और स्पीकर को आउटपुट प्रदान करने और खाना पकाने के लिए माइक्रोवेव को नियंत्रित करने के लिए एक बहुत छोटा कंप्यूटर होगा। यह कंप्यूटर सामान्यतः एक कंपाइलर, फाइल प्रणाली , या विकास पर्यावरण चलाने के लिए पर्याप्त शक्तिशाली नहीं होता है।
- कई मशीनों के लिए संकलन। उदाहरण के लिए, एक कंपनी ऑपरेटिंग प्रणाली के कई भिन्न -भिन्न संस्करणों का समर्थन करना चाहती है या कई भिन्न -भिन्न ऑपरेटिंग प्रणाली ों का समर्थन करना चाहती है। एक क्रॉस कंपाइलर का उपयोग करके, इनमें से प्रत्येक लक्ष्य के लिए कंपाइलिंग करने के लिए एक एकल निर्माण वातावरण स्थापित किया जा सकता है।
- एक सर्वर फार्म पर संकलन। कई मशीनों के लिए कंपाइलिंग के समान, एक जटिल निर्माण जिसमें कई कंपाइलिंग संचालन सम्मलित हैं, किसी भी मशीन पर निष्पादित किया जा सकता है, जो कि इसके अंतर्निहित हार्डवेयर या ऑपरेटिंग प्रणाली संस्करण पर ध्यान दिए बिना मुक्त है।
- बूटस्ट्रैपिंग (संकलक) एक नए प्लेटफॉर्म के लिए। एक नए प्लेटफ़ॉर्म के लिए सॉफ़्टवेयर विकसित करते समय, या भविष्य के प्लेटफ़ॉर्म के एमुलेटर, ऑपरेटिंग प्रणाली और एक देशी कंपाइलर जैसे आवश्यक टूल को संकलित करने के लिए एक क्रॉस कंपाइलर का उपयोग करता है।
- कमोडोर 64 या ऐप्पल II जैसे पुराने अब-अप्रचलित प्लेटफार्मों के लिए एमुलेटर के लिए मूल कोड का कंपाइलिंग उत्साही लोगों द्वारा किया जाता है जो वर्तमान प्लेटफॉर्म पर चलने वाले क्रॉस कंपाइलर्स का उपयोग करते हैं (जैसे कि एज़्टेक सी के एमएस-डॉस एमओएस टेक्नोलॉजी 6502 क्रॉस कंपाइलर जो विन्डोज़ एक्सपी के अनुसार चल रहे हैं)।
जावा की जेवीएम जैसी आभासी मशीनों का उपयोग कुछ ऐसे कारणों को हल करता है, जिनके लिए क्रॉस कंपाइलर विकसित किए गए थे। वर्चुअल मशीन प्रतिमान एक ही कंपाइलर आउटपुट को कई लक्ष्य प्रणालियों में उपयोग करने की अनुमति देता है, चूंकि यह निरंतर आदर्श के रूप में नहीं होता है क्योंकि वर्चुअल मशीन अधिकांशतः धीमी होती हैं और संकलित प्रोग्राम केवल उस वर्चुअल मशीन वाले कंप्यूटर पर ही चलाया जा सकता है।
सामान्यतः हार्डवेयर आर्किटेक्चर भिन्न रूप में होता है, उदाहरण के लिए x86 कंप्यूटर पर एमआईपीएस आर्किटेक्चर के लिए नियत प्रोग्राम को कोड करना होता है, लेकिन क्रॉस-कंपाइलिंग तब उपयोगी होता है जब केवल ऑपरेटिंग प्रणाली का वातावरण भिन्न होता है, जैसे कि लिनक्स के अनुसार एकफ्री बीएसडी प्रोग्राम को संकलित किया जाता है या फिर सिर्फ एक प्रणाली लाइब्रेरी जैसे कि जब एक ग्लिक होस्ट पर यूक्लिबैक वाले प्रोग्राम को संकलित किया जाता है।
कैनेडियन क्रॉस
कैनेडियन क्रॉस अन्य मशीनों के लिए क्रॉस कंपाइलर्स बनाने की एक प्रोद्योगिकीय के रूप में होती है, जहां मूल मशीन लक्ष्य से बहुत धीमी या कम सुविधाजनक होती है,। तीन मशीनों A, B, और C को देखते हुए, एक मशीन A का उपयोग करता है एक क्रॉस कंपाइलर बनाने के लिए आईए-32 प्रोसेसर पर विन्डोज़ एक्सपी चलता है, जो मशीन B पर चलता है उदाहरण के लिए x86-64 प्रोसेसर पर मैक ओएस एक्स मशीन C के लिए निष्पादन योग्य बनाने के लिए एंड्रॉयड को एआरएम प्रोसेसर पर चलाना होता है। इस उदाहरण में व्यावहारिक लाभ यह है कि मशीन A धीमी होती है, लेकिन उसके पास मालिकाना संकलक होता है, जबकि मशीन B तेज़ होती है, लेकिन उसका कोई संकलक नहीं होता है और मशीन C कंपाइलिंग के लिए उपयोग किए जाने के लिए अव्यावहारिक रूप से धीमी होती है।
जीसीसी के साथ कैनेडियन क्रॉस का उपयोग करते समय, और जैसा कि इस उदाहरण में है, इसमें चार कंपाइलर सम्मलित हो सकते हैं
- मशीन ए (1) के लिए 'मालिकाना नेटिव कंपाइलर' उदाहरण के लिए माइक्रोसॉफ्ट विजुअल स्टूडियो से कंपाइलर का उपयोग मशीन ए (2) के लिए जीसीसी नेटिव कंपाइलर बनाने के लिए किया जाता है।
- मशीन A (2) के लिए जीसीसी नेटिव कंपाइलर का उपयोग मशीन A से मशीन B (3) तक जीसीसी क्रॉस कंपाइलर बनाने के लिए किया जाता है
- जीसीसी क्रॉस कंपाइलर मशीन ए से मशीन बी (3) का उपयोग जीसीसी क्रॉस कंपाइलर मशीन बी से मशीन सी (4) बनाने के लिए किया जाता है
अंतिम-परिणाम क्रॉस कंपाइलर (4) बिल्ड मशीन A पर नहीं चल पाएगा; इस के अतिरिक्त यह एक एप्लिकेशन को निष्पादन योग्य कोड में संकलित करने के लिए मशीन बी पर चलता है, जिसे मशीन सी में कॉपी किया जाता है और मशीन सी पर निष्पादित किया जाता है।
उदाहरण के लिए, नेटबीएसडी एक पॉज़िक्स यूनिक्स शेल स्क्रिप्ट प्रदान करता है जिसका नाम बिल्ड.एसएच है जो पहले होस्ट के कंपाइलर के साथ अपना टूल चैन बनाता है; बदले में इसका उपयोग क्रॉस कंपाइलर बनाने के लिए किया जाता है। जिसका उपयोग पूरे प्रणाली को बनाने के लिए किया जाएगा।
कैनेडियन क्रॉस शब्द इसलिए आया क्योंकि जिस समय इन विषय पर चर्चा चल रही थी, उस समय कनाडा में तीन राष्ट्रीय राजनीतिक दल थे।[1]
प्रारंभिक क्रॉस कंपाइलर्स की समयरेखा
![[icon]](/wiki/File:Wiki_letter_w_cropped.svg){kind=small} | This section needs expansion. You can help by adding to it. (July 2012) |
- 1979 - अल्गोल 68सी ने जेडकोड उत्पन्न किया; इसने वैकल्पिक प्लेटफॉर्म पर कंपाइलर और अन्य अल्गोल 68 अनुप्रयोगों को पोर्ट करने में सहायता की थी। अल्गोल 68C कंपाइलर को संकलित करने के लिए लगभग 120 KB मेमोरी की आवश्यकता होती है। जेड80 के साथ इसकी 64 केबी मेमोरी वास्तव में कंपाइलर को संकलित करने के लिए बहुत छोटी होती है। इसलिए जेड80 के लिए कंपाइलर को बड़े कैप कंप्यूटर या आईबीएम प्रणाली /370 मेनफ्रेम से संकलित किया जाता है।
जीसीसी और क्रॉस संकलन
जीसीसी, कंपाइलरों का एक मुफ्त सॉफ्टवेयर संग्रह क्रॉस कंपाइल के लिए स्थापित किया जाता है। यह कई प्लेटफॉर्म और भाषाओं को सपोर्ट करता है।
जीसीसी के लिए आवश्यक है कि प्रत्येक लक्षित प्लेटफॉर्म के लिए बिनुटिल्स की एक संकलित प्रति उपलब्ध होती है। जीएनयू असेंबलर विशेष रूप से महत्वपूर्ण होते है। इसलिए, बिनुटिल्स को पहले सही ढंग से संकलित करना पड़ता है, जो कुछ लक्ष्य को कॉन्फ़िगर स्क्रिप्ट पर भेजे गए लक्ष्य को स्विच करना है। जीसीसी को भी उसी लक्ष्य विकल्प के साथ कॉन्फ़िगर करना होता है। तब जीसीसी को सामान्य रूप से चलाया जा सकता है परंतु बिनुटिल्स द्वारा बनाए गए उपकरण पथ (कंप्यूटिंग) में उपलब्ध होता है, जो कि यूनिक्स पर बैश के साथ ऑपरेटिंग प्रणाली जैसे निम्नलिखित का उपयोग करके किया जा सकता है।
PATH=/path/to/binutils/bin:${PATH} बनाना
क्रॉस कंपाइलिंग जीसीसी के लिए आवश्यक होता है, कि लक्ष्य प्लेटफॉर्म के सी मानक लाइब्रेरी का एक भाग होस्ट प्लेटफॉर्म पर उपलब्ध होता है। प्रोग्रामर पूर्ण सी लाइब्रेरी को संकलित करना चुन सकता है, लेकिन यह विकल्प अविश्वसनीय हो सकता है। विकल्प न्यूलिब का उपयोग करना है, जो एक छोटी सी लाइब्रेरी है जिसमें सी (प्रोग्रामिंग भाषा) स्रोत कोड को संकलित करने के लिए सबसे आवश्यक घटक के रूप में सम्मलित होता है।
जीएनयू ऑटोटूलस पैकेज अर्थात ऑटोकॉन्फ़ ऑटोमेक और लिबटूल एक बिल्ड प्लेटफ़ॉर्म, एक होस्ट प्लेटफ़ॉर्म और लक्ष्य प्लेटफ़ॉर्म की धारणा का उपयोग करते हैं। बिल्ड प्लेटफॉर्म वह जगह होती है, जहां कंपाइलर वास्तव में संकलित होता है। ज्यादातर स्थितियो में बिल्ड को अपरिभाषित रूप में छोड़ दिया जाता है यह होस्ट से डिफ़ॉल्ट रूप में होता है। होस्ट प्लेटफ़ॉर्म वह होता है जहाँ कंपाइलर से आउटपुट कलाकृतियों को निष्पादित किया जाता है चाहे आउटपुट कोई अन्य कंपाइलर हो या नहीं। लक्ष्य प्लेटफ़ॉर्म का उपयोग तब किया जाता है जब क्रॉस-कंपाइलिंग कंपाइल होता है, यह दर्शाता है कि पैकेज किस प्रकार का ऑब्जेक्ट कोड उत्पन्न करेगा; अन्यथा लक्ष्य प्लेटफ़ॉर्म सेटिंग अप्रासंगिक रूप में होता है।[2] उदाहरण के लिए, एक ड्रीमकास्ट पर चलने वाले वीडियो गेम को क्रॉस-कंपाइल करने पर विचार किया जा रहा है। मशीन जहां गेम को संकलित किया गया है वह बिल्ड प्लेटफॉर्म है जबकि ड्रीमकास्ट होस्ट प्लेटफॉर्म है। नाम होस्ट तथा लक्ष्य संकलक के सापेक्ष उपयोग किये जाते है तथा सन और ग्रैडसन की तरह स्थानांतरित किए जा रहे हैं।[3]
एम्बेडेड लिनक्स डेवलपर्स द्वारा लोकप्रिय रूप से उपयोग की जाने वाली एक अन्य विधि में स्क्रैचबॉक्स , स्क्रैचबॉक्स 2, या पीरुट जैसे विशेष सैंडबॉक्स के साथ जीसीसी कंपाइलर्स का संयोजन सम्मलित होता है। ये उपकरण एक चिरोटेड सैंडबॉक्स बनाते हैं जहां प्रोग्रामर अतिरिक्त पथ सेट किए बिना आवश्यक उपकरण, लीबीसी और लाइब्रेरी बना सकता है। रनटाइम को धोखा देने के लिए सुविधाएं भी प्रदान की जाती हैं जिससे की यह विश्वास हो सके कि यह वास्तव में लक्षित लक्ष्य सीपीयू जैसे एआरएम आर्किटेक्चर पर चल रहा है; यह कॉन्फ़िगरेशन स्क्रिप्ट और बिना किसी त्रुटि के चलने की अनुमति देता है। स्क्रैचबॉक्स गैर-क्रोट किए गए विधियों की तुलना में अधिक धीमी गति से चलता है और अधिकांश उपकरण जो होस्ट पर हैं उन्हें कार्य करने के लिए स्क्रैचबॉक्स में स्थानांतरित किया जाना चाहिए।
मैक्स एज़्टेक सी क्रॉस कंपाइलर्स
श्रेवबरी, न्यू जर्सी के मैनक्स सॉफ्टवेयर प्रणाली ने 1980 के दशक की शुरुआत में आईबीएम पीसी और मैकिंटोश सहित विभिन्न प्लेटफार्मों के लिए प्रोफेशनल डेवलपर्स पर लक्षित सी कंपाइलर का उत्पादन किया है।
मैनक्स की एज़्टेक सी प्रोग्रामिंग लैंग्वेज एमएस-डॉस, ऐप्पल II, डॉस 3.3 और प्रोडोस, कमोडोर 64, मैक कंप्यूटर 68k और अमिगा सहित विभिन्न प्लेटफार्मों के लिए उपलब्ध थी।[4]
1980 के दशक से लेकर 1990 के दशक तक जारी रहा जब तक कि मैनक्स सॉफ्टवेयर प्रणाली गायब नहीं हो गया, एज़्टेक सी का एमएस-डॉस संस्करण[5] को क्रॉस कंपाइलर के रूप में या कॉमोडोर 64 तथा एपल II सहित विभिन्न प्रोसेसरों के साथ अन्य प्लेटफार्मों के लिए क्रॉस कंपाइलर के रूप में प्रस्तुत किया गया था।[6] [7] एज़्टेक सी के लिए उनके एमएस-डॉस आधारित क्रॉस कंपाइलर्स सहित इंटरनेट वितरण अभी भी उपलब्ध है। वे आज भी उपयोग में हैं।
मैनक्स का एज़्टेक सी86, उनका क्रॉस इंटेल 8086 एमएस-डॉस कंपाइलर भी एक क्रॉस कंपाइलर के रूप में होता है। चूंकि यह कमोडोर 64 और ऐप्पल II के लिए उनके एज़्टेक सी 65 एमओएस प्रोद्योगिकीय 6502 क्रॉस कंपाइलर्स के रूप में है, जैसे एक भिन्न प्रोसेसर के लिए कोड संकलित नहीं करता है, तथा प्रोसेसर के 16-बिट 8086 फॅमिली के लिए तत्कालीन हेरिटेज ऑपरेटिंग प्रणाली के लिए बाइनरी एक्ज़ीक्यूटेबल्सरूप में होते है।
जब आईबीएम पीसी पहली बार प्रस्तुत किया गया था तो यह ऑपरेटिंग प्रणाली के विकल्प के साथ उपलब्ध था, सीपी/एम-86 और पीसी डॉस उनमें से दो के रूप में थे। एज़्टेक सी86 को आईबीएम पीसी ऑपरेटिंग प्रणाली के लिए कोड बनाने के लिए लिंक लाइब्रेरी प्रदान की गई थी। 1980 के दशक के समय एज़्टेक सी86 (3.xx, 4.xx और 5.xx) के बाद के संस्करणों ने एमएस-डॉस अस्थायी संस्करण 1 और 2 के लिए समर्थन जोड़ा[8] और जो बेसलाइन एमएस-डॉस संस्करण 3 की तुलना में कम मजबूत थे और बाद में जिन्हें एज़्टेक सी86 ने अपने अंत तक लक्षित किया।
अंत में, एज़्टेक सी86 को सी लैंग्वेज डेवलपर्स को रोमेबल इमेज हेक्स कोड बनाने की क्षमता प्रदान की गई। जिसे तब सीधे एक 8086 पर रोम बर्नर का उपयोग करके हस्तांतरित किया जा सकता है। पैरावर्चुअलाइजेशन आज अधिक सामान्य हो सकता है, लेकिन निम्न-स्तरीय रोम कोड बनाने का अभ्यास उन वर्षों के समय प्रति व्यक्ति अधिक सामान्य रूप में था, जब उपकरण चालक का विकास अधिकांशतः व्यक्तिगत अनुप्रयोगों के लिए एप्लिकेशन प्रोग्रामर द्वारा किया जाता था और नए उपकरण में कुटीर उद्योग के बराबर होता था। यह अनुप्रयोग प्रोग्रामर के लिए निर्माता के समर्थन के बिना सीधे हार्डवेयर के साथ इंटरफेस करने के लिए असामान्य नहीं था.यह प्रक्रिया आज एम्बेडेड प्रणाली विकास के समान थी।
थॉमस फेनविक और जेम्स गुडनाउ II एज़्टेक-सी के दो प्रमुख डेवलपर के रूप में थे। फेनविक बाद में माइक्रोसॉफ्ट विंडोज सीई कर्नेल (ऑपरेटिंग प्रणाली ) या एनके (न्यू कर्नेल) के लेखक के रूप में उल्लेखनीय हो गया, क्योंकि इसे तब कहा जाता था।[9]
माइक्रोसॉफ्ट सी क्रॉस कंपाइलर
प्रारंभिक इतिहास - 1980 के दशक
Microsoft C (MSC) का दूसरों की तुलना में छोटा इतिहास है[10] 1980 के दशक से डेटिंग। पहला Microsoft C कंपाइलर उसी कंपनी द्वारा बनाया गया था जिसने Lattice C बनाया था और MSC 4 के रिलीज़ होने तक Microsoft द्वारा अपने स्वयं के रूप में रीब्रांड किया गया था, जो कि पहला संस्करण था जिसे Microsoft ने स्वयं निर्मित किया था।[11] 1987 में, कई डेवलपर्स ने माइक्रोसॉफ्ट सी पर स्विच करना शुरू कर दिया था, और कई अन्य माइक्रोसॉफ्ट विंडोज के वर्तमान विकास के पूरे विकास का पालन करेंगे। क्लिपर (प्रोग्रामिंग भाषा) और बाद में बिगुल (प्रोग्रामिंग भाषा) जैसे उत्पाद सामने आए, जिन्होंने क्रॉस लैंग्वेज तकनीकों का उपयोग करके आसान डेटाबेस एप्लिकेशन डेवलपमेंट की पेशकश की, जिससे उनके प्रोग्राम के कुछ हिस्से को माइक्रोसॉफ्ट सी के साथ संकलित किया जा सके।
बोरलैंड (कैलिफोर्निया कंपनी) माइक्रोसॉफ्ट द्वारा अपना पहला सी उत्पाद जारी करने से पहले खरीद के लिए उपलब्ध था।
बोरलैंड से बहुत पहले, बीएसडी यूनिक्स (बर्कले विश्वविद्यालय) ने सी लैंग्वेज के लेखकों से सी प्राप्त किया था: ब्रायन कर्निघन और डेनिस रिची जिन्होंने एटी एंड टी (प्रयोगशालाओं) के लिए काम करते हुए इसे एक साथ लिखा था। K&R की मूल ज़रूरतें asm 1st स्तर के पार्स किए गए सिंटैक्स को बदलने के लिए न केवल सुरुचिपूर्ण द्वितीय स्तर के पार्स किए गए सिंटैक्स थे: इसे डिज़ाइन किया गया था जिससे की प्रत्येक प्लेटफ़ॉर्म का समर्थन करने के लिए asm की न्यूनतम मात्रा लिखी जाए (C का मूल डिज़ाइन C के साथ C का उपयोग करके कंपाइलिंग को पार करने की क्षमता थी) प्रति प्लेटफ़ॉर्म कम से कम समर्थन कोड, जिसकी उन्हें आवश्यकता थी।) साथ ही कल का C सीधे ASM कोड से संबंधित है जहाँ प्लेटफ़ॉर्म निर्भर नहीं है। आज का सी (ज्यादातर सी++) अब सी संगत नहीं है और अंतर्निहित एएसएम कोड किसी दिए गए प्लेटफॉर्म पर लिखे जाने से बहुत भिन्न हो सकता है (लिनक्स में: यह कभी-कभी वितरक विकल्पों के साथ लाइब्रेरी कॉल को बदल देता है और चक्कर लगाता है)। आज की C एक 3rd या 4th लेवल लैंग्वेज है जो पुराने तरीके से 2nd लेवल लैंग्वेज की तरह उपयोग की जाती है।
1987
सी प्रोग्राम लंबे समय से सभा की लैंग्वेज में लिखे मॉड्यूल से जुड़े हुए थे। अधिकांश सी कंपाइलर्स (यहां तक कि वर्तमान कंपाइलर्स) एक असेंबली लैंग्वेज पास प्रदान करते हैं (जिसे दक्षता के लिए ट्वीक किया जा सकता है और फिर संयोजन के बाद बाकी कार्यक्रम से जुड़ा हुआ है)।
एज़्टेक-सी जैसे कंपाइलर्स ने सब कुछ असेंबली लैंग्वेज में एक भिन्न पास के रूप में परिवर्तित कर दिया और फिर कोड को एक भिन्न पास में इकट्ठा किया, और उनके बहुत ही कुशल और छोटे कोड के लिए विख्यात थे, लेकिन 1987 तक Microsoft C में निर्मित ऑप्टिमाइज़र बहुत अच्छा था, और केवल किसी कार्यक्रम के मिशन के महत्वपूर्ण भागों को सामान्यतः पुनर्लेखन के लिए माना जाता था। वास्तव में, सी लैंग्वेज प्रोग्रामिंग ने सबसे निचले स्तर की लैंग्वेज के रूप में ले लिया था, प्रोग्रामिंग एक बहु-अनुशासनात्मक विकास उद्योग बन गया था और परियोजनाएं बड़ी हो रही थीं, प्रोग्रामर उच्च स्तरीय भाषाओं में उपयोगकर्ता इंटरफेस और डेटाबेस इंटरफेस लिख रहे थे, और एक आवश्यकता सामने आई थी क्रॉस लैंग्वेज डेवलपमेंट जो आज भी जारी है।
1987 तक, MSC 5.1 की रिलीज़ के साथ, Microsoft ने एमएस-डॉस के लिए एक क्रॉस लैंग्वेज डेवलपमेंट एनवायरनमेंट की पेशकश की। असेंबली लैंग्वेज (MASM) और Microsoft की अन्य भाषाओं में QuickBASIC, पास्कल (प्रोग्रामिंग भाषा), और फोरट्रान सहित लिखे गए 16-बिट बाइनरी ऑब्जेक्ट कोड को एक साथ एक प्रोग्राम में जोड़ा जा सकता है, एक प्रक्रिया में वे मिश्रित लैंग्वेज प्रोग्रामिंग और अब इंटरलैंग्वेज कॉलिंग कहलाते हैं।[12] यदि इस मिश्रण में BASIC का उपयोग किया गया था, तो आंतरिक रनटाइम प्रणाली का समर्थन करने के लिए मुख्य प्रोग्राम का BASIC में होना आवश्यक था, जो कचरा संग्रह के लिए आवश्यक BASIC को संकलित करता था और इसके अन्य प्रबंधित संचालन जो एमएस-डॉस में QBasic जैसे BASIC दुभाषिया (कंप्यूटिंग) का अनुकरण करते थे।
सी कोड के लिए कॉलिंग कन्वेंशन, विशेष रूप से, कॉल स्टैक पर रिवर्स ऑर्डर में पैरामीटर पास करना था और प्रोसेसर रजिस्टर के अतिरिक्त स्टैक पर मान वापस करना था। सभी भाषाओं को एक साथ काम करने के लिए अन्य प्रोग्रामिंग नियम थे, लेकिन यह विशेष नियम क्रॉस लैंग्वेज डेवलपमेंट के माध्यम से कायम रहा जो Microsoft Windows 16- और 32-बिट संस्करणों में और OS/2 के लिए कार्यक्रमों के विकास में जारी रहा, और जो अभी भी जारी है। इस दिन। इसे पास्कल कॉलिंग कन्वेंशन के रूप में जाना जाता है।
एक अन्य प्रकार का क्रॉस कंपाइलिंग जो इस समय के समय Microsoft C का उपयोग किया गया था, खुदरा अनुप्रयोगों में था, जिसके लिए प्रतीक टेक्नोलॉजीज PDT3100 (भंडार लेने के लिए प्रयुक्त) जैसे तरकीब अपने हाथ में है की आवश्यकता होती है, जो Intel 8088 आधारित बारकोड रीडर पर लक्षित एक लिंक लाइब्रेरी प्रदान करता है। एप्लिकेशन को होस्ट कंप्यूटर पर बनाया गया था और फिर हैंडहेल्ड उपकरण (एक सीरियल केबल के माध्यम से) में स्थानांतरित कर दिया गया था, जहां इसे चलाया गया था, जैसा कि आज उसी बाजार के लिए किया जाता है, जो MOTOROLA जैसी कंपनियों द्वारा विंडोज मोबाइल का उपयोग करके किया जाता है, जिन्होंने सिंबल खरीदा था।
1990 के दशक की शुरुआत
1990 के दशक के समय और MSC 6 (उनका पहला ANSI C अनुपालक संकलक) के साथ शुरुआत करते हुए Microsoft ने अपने C संकलकों को उभरते हुए विंडोज बाजार पर और OS/2 पर और GUI कार्यक्रमों के विकास पर फिर से ध्यान केंद्रित किया। एमएस-डॉस पक्ष पर MSC 6 के माध्यम से मिश्रित लैंग्वेज संगतता बनी रही, लेकिन Microsoft Windows 3.0 और 3.1 के लिए API को MSC 6 में लिखा गया था। MSC 6 को 32-बिट असेंबली के लिए समर्थन प्रदान करने और कार्यसमूहों के लिए उभरते विंडोज़ के लिए समर्थन प्रदान करने के लिए भी विस्तारित किया गया था। और Windows NT जो Windows XP के लिए नींव तैयार करेगा। थंक नामक एक प्रोग्रामिंग अभ्यास को 16- और 32-बिट प्रोग्राम के बीच पारित करने की अनुमति देने के लिए प्रस्तुत किया गया था, जो अखंड प्रणाली 16-बिट एमएस-डॉस अनुप्रयोगों में पसंदीदा स्थिर बंधन के अतिरिक्त रनटाइम बाइंडिंग (गतिशील लिंकिंग) का लाभ उठाता था। स्थैतिक बंधन अभी भी कुछ देशी कोड डेवलपर्स द्वारा समर्थित है, लेकिन सामान्यतः क्षमता परिपक्वता मॉडल (सीएमएम) जैसी नई सर्वोत्तम प्रथाओं के लिए आवश्यक कोड पुन: उपयोग की डिग्री प्रदान नहीं करता है।
एमएस-डॉस समर्थन अभी भी Microsoft के पहले C++ कंपाइलर, MSC 7 की रिलीज़ के साथ प्रदान किया गया था, जो C प्रोग्रामिंग लैंग्वेज और एमएस-डॉस के साथ पिछड़ा संगत था और 16- और 32-बिट कोड जनरेशन दोनों का समर्थन करता था।
एमएससी ने वहीं से पदभार संभाला जहां एज़्टेक सी ने छोड़ा था। सी कंपाइलर्स के लिए बाजार हिस्सेदारी क्रॉस कंपाइलर्स में बदल गई थी, जिसने नवीनतम और सबसे बड़ी विंडोज सुविधाओं का लाभ उठाया, एक ही बंडल में सी और सी ++ की पेशकश की, और अभी भी एमएस-डॉस प्रणाली का समर्थन किया जो पहले से ही एक दशक पुराना था, और छोटी कंपनियां जो एज़्टेक सी जैसे उत्पादित संकलक अब प्रतिस्पर्धा नहीं कर सकते थे और या तो एम्बेडेड प्रणाली जैसे आला बाजारों में बदल गए या गायब हो गए।
एमएस-डॉस और 16-बिट कोड जनरेशन समर्थन MSC 8.00c तक जारी रहा, जिसे Microsoft C++ और Microsoft अनुप्रयोग स्टूडियो 1.5 के साथ बंडल किया गया था, जो Microsoft Visual Studio का अग्रदूत है जो आज Microsoft द्वारा प्रदान किया जाने वाला क्रॉस डेवलपमेंट वातावरण है।
1990 के दशक के अंत में
MSC 12 को Microsoft Visual Studio 6 के साथ जारी किया गया था और अब एमएस-डॉस 16-बिट बायनेरिज़ के लिए समर्थन प्रदान नहीं करता है, इस के अतिरिक्त 32-बिट कंसोल अनुप्रयोगों के लिए समर्थन प्रदान करता है, लेकिन Windows 95 और Windows 98 कोड जनरेशन के साथ-साथ Windows NT के लिए समर्थन प्रदान करता है। . Microsoft Windows चलाने वाले अन्य प्रोसेसर के लिए लिंक लाइब्रेरी उपलब्ध थी; एक प्रथा जो Microsoft आज भी जारी है।
MSC 13 को Visual Studio 2003 के साथ रिलीज़ किया गया था, और MSC 14 को Visual Studio 2005 के साथ रिलीज़ किया गया था, जो दोनों अभी भी Windows 95 जैसे पुराने प्रणाली के लिए कोड का उत्पादन करते हैं, लेकिन जो मोबाइल मार्केट और ARM आर्किटेक्चर सहित कई लक्षित प्लेटफॉर्म के लिए कोड तैयार करेगा।
.NET और परे
2001 में माइक्रोसॉफ्ट ने सामान्य लैंग्वेज रनटाइम (सीएलआर) विकसित किया, जिसने विजुअल स्टूडियो आईडीई में उनके .NET फ्रेमवर्क कंपाइलर के लिए कोर का गठन किया। ऑपरेटिंग प्रणाली पर यह परत जो अप्लिकेशन प्रोग्रामिंग अंतरफलक में है, विंडोज ऑपरेटिंग प्रणाली चलाने वाले प्लेटफॉर्म पर संकलित विकास भाषाओं के मिश्रण की अनुमति देती है।
.NET फ्रेमवर्क रनटाइम और सीएलआर लक्ष्य कंप्यूटर पर प्रोसेसर और उपकरणों के लिए कोर रूटीन के लिए मैपिंग परत प्रदान करते हैं। विजुअल स्टूडियो में कमांड-लाइन सी कंपाइलर विभिन्न प्रकार के प्रोसेसर के लिए मूल कोड संकलित करेगा और इसका उपयोग स्वयं कोर रूटीन बनाने के लिए किया जा सकता है।
विभिन्न प्रकार के प्रोसेसर के साथ विंडोज मशीनों पर एआरएम आर्किटेक्चर क्रॉस-कंपाइल पर विंडोज मोबाइल जैसे लक्ष्य प्लेटफॉर्म के लिए माइक्रोसॉफ्ट .NET एप्लिकेशन और माइक्रोसॉफ्ट एमुलेटर और रिमोट परिनियोजन वातावरण भी प्रदान करता है, जिसके लिए बहुत कम कॉन्फ़िगरेशन की आवश्यकता होती है, क्रॉस कंपाइलर्स के विपरीत। अन्य प्लेटफार्म।
रनटाइम लाइब्रेरी, जैसे मोनो (सॉफ़्टवेयर), क्रॉस-संकलित .NET प्रोग्राम के लिए लिनक्स जैसे अन्य ऑपरेटिंग प्रणाली के लिए अनुकूलता प्रदान करते हैं।
क्यूटी (टूलकिट) और 15 समेत इसके पूर्ववर्तियों जैसे लाइब्रेरी अन्य प्लेटफार्मों के साथ स्रोत कोड स्तर क्रॉस विकास क्षमता प्रदान करते हैं, जबकि अभी भी विंडोज संस्करण बनाने के लिए माइक्रोसॉफ्ट सी का उपयोग करते हैं। MinGW जैसे अन्य कंपाइलर भी इस क्षेत्र में लोकप्रिय हो गए हैं क्योंकि वे यूनिक्स के साथ अधिक सीधे संगत हैं मोनो (सॉफ्टवेयर) विकास के गैर-विंडोज पक्ष को सम्मलित करते हैं जिससे उन डेवलपर्स को एक परिचित निर्माण वातावरण का उपयोग करके सभी प्लेटफार्मों को लक्षित करने की अनुमति मिलती है।
फ़्री पास्कल
Free Pascal को शुरुआत से ही एक cross Compiler के रूप में विकसित किया गया था। कंपाइलर एक्जीक्यूटेबल (ppcXXX जहां XXX एक लक्षित आर्किटेक्चर है) एक ही आर्किटेक्चर के सभी ओएस के लिए एक्जीक्यूटिव (या यदि कोई आंतरिक लिंकर उपलब्ध नहीं है, या यहां तक कि यदि कोई आंतरिक असेंबलर उपलब्ध नहीं है तो सिर्फ असेंबली फाइल) बनाने में सक्षम है। उदाहरण के लिए, ppc386 i386-लिनक्स , i386-win32, i386-go32v2 (DOS) और अन्य सभी OSes के लिए निष्पादन योग्य बनाने में सक्षम है (देखें [13]). चूंकि , किसी अन्य आर्किटेक्चर के कंपाइलिंग के लिए, कंपाइलर का एक क्रॉस आर्किटेक्चर संस्करण पहले बनाया जाना चाहिए। परिणामी संकलक निष्पादन योग्य के नाम में लक्ष्य आर्किटेक्चर से पहले अतिरिक्त 'रॉस' होगा। अर्थात यदि कंपाइलर x64 को लक्षित करने के लिए बनाया गया है, तो निष्पादन योग्य ppcrossx64 होगा।
एक चुने हुए आर्किटेक्चर-ओएस के लिए संकलित करने के लिए, कंपाइलर स्विच (कंपाइलर चालक एफपीसी के लिए) -पी और -टी का उपयोग किया जा सकता है। यह तब भी किया जाता है जब संकलक स्वयं को संकलित करता है, लेकिन विकल्प CPU_TARGET और OS_TARGET के माध्यम से सेट किया जाता है। लक्ष्य प्लेटफॉर्म के लिए जीएनयू असेंबलर और लिंकर की आवश्यकता है यदि फ्री पास्कल के पास लक्ष्य प्लेटफॉर्म के लिए उपकरणों का आंतरिक संस्करण नहीं है।
क्लैंग
क्लैंग मूल रूप से एक क्रॉस कंपाइलर है, निर्माण समय पर आप चुन सकते हैं कि आप किस आर्किटेक्चर को क्लैंग को लक्षित करने में सक्षम होना चाहते हैं।
यह भी देखें
- मिनजीडब्ल्यू
- स्क्रैचबॉक्स
- नि: शुल्क पास्कल
- क्रॉस असेम्बलर
संदर्भ
- ↑ "4.9 Canadian Crosses". CrossGCC. Archived from the original on October 9, 2004. Retrieved 2012-08-08.
This is called a `Canadian Cross' because at the time a name was needed, Canada had three national parties.
- ↑ "Cross-Compilation (Automake)".
- ↑ "Cross compilation".
- ↑ "Obsolete Macintosh Computers". Archived from the original on 2008-02-26. Retrieved 2008-03-10.
- ↑ Aztec C
- ↑ Commodore 64
- ↑ Apple II
- ↑ MS-DOS Timeline Archived 2008-05-01 at the Wayback Machine
- ↑ Inside Windows CE (search for Fenwick)
- ↑ Microsoft Language Utility Version History
- ↑ History of PC based C-compilers Archived December 15, 2007, at the Wayback Machine
- ↑ Which Basic Versions Can CALL C, FORTRAN, Pascal, MASM
- ↑ "Free Pascal Supported Platform List". Platform List. Retrieved 2010-06-17.
i386
बाहरी संबंध
- Cross Compilation Tools – reference for configuring GNU cross compilation tools
- Building Cross Toolchains with जीसीसी is a wiki of other जीसीसी cross-compilation references
- Scratchbox is a toolkit for लिनक्स cross-compilation to ARM and x86 targets
- Grand Unified Builder (GUB) for लिनक्स to cross-compile multiple architectures e.g.:Win32/Mac OS/FreeBSD/लिनक्स used by GNU LilyPond
- Crosstool is a helpful toolchain of scripts, which create a लिनक्स cross-compile environment for the desired architecture, including embedded systems
- crosstool-NG is a rewrite of Crosstool and helps building toolchains.
- buildroot is another set of scripts for building a uClibc-based toolchain, usually for embedded systems. It is utilized by OpenWrt.
- ELDK (Embedded लिनक्स Development Kit). Utilized by Das U-Boot.
- T2 SDE is another set of scripts for building whole लिनक्स Systems based on either GNU libC, uClibc or dietlibc for a variety of architectures
- Cross लिनक्स fरोम Scratch Project
- IBM has a very clear structured tutorial about cross-building a जीसीसी toolchain.
- (in French) Cross-compilation avec जीसीसी 4 sous Windows pour लिनक्स - A tutorial to build a cross-जीसीसी toolchain, but fरोम Windows to लिनक्स , a subject rarely developed
