क्रॉस कंपाइलर

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

क्रॉस कंपाइलर, एक डेवलपमेंट होस्ट से एकाधिक प्लेटफॉर्म के लिए कोड को संकलित करने के लिए उपयोगी होते है। लक्ष्य प्लेटफॉर्म पर प्रत्यक्ष कंपाइलिंग अव्यावहारिक रूप में होता है, उदाहरण के लिए एम्बेडेड प्रणाली पर सीमित कंप्यूटिंग संसाधनों के साथ.उपयोगी होता है।

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

प्रयोग

क्रॉस कंपाइलर का मौलिक उपयोग निर्माण वातावरण को लक्षित वातावरण से भिन्न करना है। यह कई स्थितियों में उपयोगी है

• एम्बेडेड प्रणाली जहां उपकरण में अत्यधिक सीमित संसाधन होते हैं। उदाहरण के लिए, एक माइक्रोवेव ओवन में अपने कीपैड और डोर सेंसर को पढ़ने, डिजिटल डिस्प्ले और स्पीकर को आउटपुट प्रदान करने और खाना पकाने के लिए माइक्रोवेव को नियंत्रित करने के लिए एक बहुत छोटा कंप्यूटर होगा। यह कंप्यूटर सामान्यतः एक कंपाइलर, फाइल सिस्टम, या विकास पर्यावरण चलाने के लिए पर्याप्त शक्तिशाली नहीं होता है।
• कई मशीनों के लिए संकलन। उदाहरण के लिए, एक कंपनी ऑपरेटिंग प्रणाली के कई भिन्न -भिन्न संस्करणों का समर्थन करना चाहती है या कई भिन्न -भिन्न ऑपरेटिंग सिस्टमों का समर्थन करना चाहती है। एक क्रॉस कंपाइलर का उपयोग करके, इनमें से प्रत्येक लक्ष्य के लिए कंपाइलिंग करने के लिए एक एकल निर्माण वातावरण स्थापित किया जा सकता है।
• एक सर्वर फार्म पर संकलन। कई मशीनों के लिए कंपाइलिंग के समान, एक जटिल निर्माण जिसमें कई कंपाइलिंग संचालन सम्मलित हैं, किसी भी मशीन पर निष्पादित किया जा सकता है, जो कि इसके अंतर्निहित हार्डवेयर या ऑपरेटिंग प्रणाली संस्करण पर ध्यान दिए बिना मुक्त है।
• बूटस्ट्रैपिंग (संकलक) एक नए प्लेटफॉर्म के लिए। एक नए प्लेटफ़ॉर्म के लिए सॉफ़्टवेयर विकसित करते समय, या भविष्य के प्लेटफ़ॉर्म के एमुलेटर, ऑपरेटिंग प्रणाली और एक देशी कंपाइलर जैसे आवश्यक टूल को संकलित करने के लिए एक क्रॉस कंपाइलर का उपयोग करता है।
• कमोडोर 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 पर नहीं चल पाएगा; इस के अतिरिक्त यह एक एप्लिकेशन को निष्पादन योग्य कोड में संकलित करने के लिए मशीन बी पर चलता है, जिसे मशीन सी में कॉपी किया जाता है और मशीन सी पर निष्पादित किया जाता है।

उदाहरण के लिए, नेटबीएसडी एक पॉज़िक्स यूनिक्स शेल स्क्रिप्ट प्रदान करता है जिसका नाम बिल्ड.एसएच है जो पहले होस्ट के कंपाइलर के साथ अपना टूल चैन बनाता है; बदले में इसका उपयोग क्रॉस कंपाइलर बनाने के लिए किया जाता है। जिसका उपयोग पूरे प्रणाली को बनाने के लिए किया जाएगा।

कैनेडियन क्रॉस शब्द इसलिए आया क्योंकि जिस समय इन विषय पर चर्चा चल रही थी, उस समय कनाडा में तीन राष्ट्रीय राजनीतिक दल थे।

प्रारंभिक क्रॉस कंपाइलर्स की समयरेखा

• 1979 - अल्गोल 68सी ने जेडकोड उत्पन्न किया; इसने वैकल्पिक प्लेटफॉर्म पर कंपाइलर और अन्य अल्गोल 68 अनुप्रयोगों को पोर्ट करने में सहायता की थी। अल्गोल 68C कंपाइलर को संकलित करने के लिए लगभग 120 KB मेमोरी की आवश्यकता होती है। जेड80 के साथ इसकी 64 केबी मेमोरी वास्तव में कंपाइलर को संकलित करने के लिए बहुत छोटी होती है। इसलिए जेड80 के लिए कंपाइलर को बड़े कैप कंप्यूटर या आईबीएम सिस्टम/370 मेनफ्रेम से संकलित किया जाता है।

जीसीसी और क्रॉस संकलन

जीसीसी, कंपाइलरों का एक मुफ्त सॉफ्टवेयर संग्रह क्रॉस कंपाइल के लिए स्थापित किया जाता है। यह कई प्लेटफॉर्म और भाषाओं को सपोर्ट करता है।

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

PATH=/path/to/binutils/bin:${PATH} बनाना

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

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

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

मैक्स एज़्टेक सी क्रॉस कंपाइलर्स

Shrewsbury, न्यू जर्सी, न्यू जर्सी के Manx Software Systems ने 1980 के दशक की शुरुआत में IBM PC और Macintosh सहित विभिन्न प्लेटफार्मों के लिए पेशेवर डेवलपर्स पर लक्षित कंपाइलर का उत्पादन किया।

मैक्स की एज़्टेक सीसी (प्रोग्रामिंग भाषा) MS-DOS, Apple II, Apple DOS|DOS 3.3 और ProDOS, कमोडोर 64, Mac (कंप्यूटर) 68k सहित विभिन्न प्लेटफार्मों के लिए उपलब्ध थी। और अमिगा।

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

मैनक्स का एज़्टेक C86, उनका मूल मोड Intel 8086 MS-DOS कंपाइलर भी एक क्रॉस कंपाइलर था। चूंकि यह कमोडोर 64 और ऐप्पल II के लिए उनके एज़्टेक सी 65 एमओएस टेक्नोलॉजी 6502 क्रॉस कंपाइलर्स जैसे एक भिन्न प्रोसेसर के लिए कोड संकलित नहीं करता था, इसने प्रोसेसर के 16-बिट 8086 परिवार के लिए तत्कालीन विरासत ऑपरेटिंग प्रणाली के लिए बाइनरी एक्ज़ीक्यूटेबल्स बनाए।

जब IBM PC पहली बार पेश किया गया था तो यह ऑपरेटिंग प्रणाली के विकल्प के साथ उपलब्ध था, CP/M-86 और PC DOS उनमें से दो थे। एज़्टेक C86 को आईबीएम पीसी ऑपरेटिंग प्रणाली दोनों के लिए कोड बनाने के लिए लिंक लाइब्रेरी प्रदान की गई थी। 1980 के दशक के समय एज़्टेक C86 (3.xx, 4.xx और 5.xx) के बाद के संस्करणों ने MS-DOS अस्थायी संस्करण 1 और 2 के लिए समर्थन जोड़ा और जो बेसलाइन MS-DOS संस्करण 3 की तुलना में कम मजबूत थे और बाद में जिन्हें एज़्टेक C86 ने अपने अंत तक लक्षित किया।

अंत में, एज़्टेक C86 ने C भाषा डेवलपर्स को ROM छवि बनाने की क्षमता प्रदान की। रोम-सक्षम हेक्साडेसिमल| हेक्स कोड जिसे तब केवल पढ़ने के लिये मेमोरी का उपयोग करके सीधे 8086 आधारित प्रोसेसर में स्थानांतरित किया जा सकता था। पैरावर्चुअलाइजेशन आज अधिक सामान्य हो सकता है, लेकिन निम्न-स्तरीय ROM कोड बनाने का अभ्यास उन वर्षों के समय प्रति व्यक्ति अधिक सामान्य था, जब उपकरण ड्राइवर का विकास अधिकांशतः व्यक्तिगत अनुप्रयोगों के लिए एप्लिकेशन प्रोग्रामर द्वारा किया जाता था, और नए उपकरण एक कुटीर उद्योग के बराबर होते थे। निर्माता से समर्थन के बिना सीधे हार्डवेयर के साथ इंटरफ़ेस करने के लिए एप्लिकेशन प्रोग्रामर के लिए यह असामान्य नहीं था। यह अभ्यास आज के एम्बेडेड प्रणाली के समान था।

थॉमस फेनविक और जेम्स गुडनाउ II एज़्टेक-सी के दो प्रमुख डेवलपर थे। फेनविक बाद में माइक्रोसॉफ्ट विंडोज सीई कर्नेल (ऑपरेटिंग सिस्टम) या एनके (न्यू कर्नेल) के लेखक के रूप में उल्लेखनीय हो गया, क्योंकि इसे तब कहा जाता था।

माइक्रोसॉफ्ट सी क्रॉस कंपाइलर

प्रारंभिक इतिहास - 1980 के दशक

Microsoft C (MSC) का दूसरों की तुलना में छोटा इतिहास है 1980 के दशक से डेटिंग। पहला Microsoft C कंपाइलर उसी कंपनी द्वारा बनाया गया था जिसने Lattice C बनाया था और MSC 4 के रिलीज़ होने तक Microsoft द्वारा अपने स्वयं के रूप में रीब्रांड किया गया था, जो कि पहला संस्करण था जिसे Microsoft ने स्वयं निर्मित किया था। 1987 में, कई डेवलपर्स ने माइक्रोसॉफ्ट सी पर स्विच करना शुरू कर दिया था, और कई अन्य माइक्रोसॉफ्ट विंडोज के वर्तमान विकास के पूरे विकास का पालन करेंगे। क्लिपर (प्रोग्रामिंग भाषा) और बाद में बिगुल (प्रोग्रामिंग भाषा) जैसे उत्पाद सामने आए, जिन्होंने क्रॉस लैंग्वेज तकनीकों का उपयोग करके आसान डेटाबेस एप्लिकेशन डेवलपमेंट की पेशकश की, जिससे उनके प्रोग्राम के कुछ हिस्से को माइक्रोसॉफ्ट सी के साथ संकलित किया जा सके।

बोरलैंड (कैलिफोर्निया कंपनी) माइक्रोसॉफ्ट द्वारा अपना पहला सी उत्पाद जारी करने से पहले खरीद के लिए उपलब्ध था।

बोरलैंड से बहुत पहले, बीएसडी यूनिक्स (बर्कले विश्वविद्यालय) ने सी भाषा के लेखकों से सी प्राप्त किया था: ब्रायन कर्निघन और डेनिस रिची जिन्होंने एटी एंड टी (प्रयोगशालाओं) के लिए काम करते हुए इसे एक साथ लिखा था। K&R की मूल ज़रूरतें asm 1st स्तर के पार्स किए गए सिंटैक्स को बदलने के लिए न केवल सुरुचिपूर्ण द्वितीय स्तर के पार्स किए गए सिंटैक्स थे: इसे डिज़ाइन किया गया था जिससे की प्रत्येक प्लेटफ़ॉर्म का समर्थन करने के लिए asm की न्यूनतम मात्रा लिखी जाए (C का मूल डिज़ाइन C के साथ C का उपयोग करके कंपाइलिंग को पार करने की क्षमता थी) प्रति प्लेटफ़ॉर्म कम से कम समर्थन कोड, जिसकी उन्हें आवश्यकता थी।) साथ ही कल का C सीधे ASM कोड से संबंधित है जहाँ प्लेटफ़ॉर्म निर्भर नहीं है। आज का सी (ज्यादातर सी++) अब सी संगत नहीं है और अंतर्निहित एएसएम कोड किसी दिए गए प्लेटफॉर्म पर लिखे जाने से बहुत भिन्न हो सकता है (लिनक्स में: यह कभी-कभी वितरक विकल्पों के साथ लाइब्रेरी कॉल को बदल देता है और चक्कर लगाता है)। आज की C एक 3rd या 4th लेवल लैंग्वेज है जो पुराने तरीके से 2nd लेवल लैंग्वेज की तरह उपयोग की जाती है।

1987

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

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

1987 तक, MSC 5.1 की रिलीज़ के साथ, Microsoft ने MS-DOS के लिए एक क्रॉस लैंग्वेज डेवलपमेंट एनवायरनमेंट की पेशकश की। असेंबली लैंग्वेज (MASM) और Microsoft की अन्य भाषाओं में QuickBASIC, पास्कल (प्रोग्रामिंग भाषा), और फोरट्रान सहित लिखे गए 16-बिट बाइनरी ऑब्जेक्ट कोड को एक साथ एक प्रोग्राम में जोड़ा जा सकता है, एक प्रक्रिया में वे मिश्रित भाषा प्रोग्रामिंग और अब इंटरलैंग्वेज कॉलिंग कहलाते हैं। यदि इस मिश्रण में BASIC का उपयोग किया गया था, तो आंतरिक रनटाइम प्रणाली का समर्थन करने के लिए मुख्य प्रोग्राम का BASIC में होना आवश्यक था, जो कचरा संग्रह के लिए आवश्यक BASIC को संकलित करता था और इसके अन्य प्रबंधित संचालन जो MS-DOS में 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 कार्यक्रमों के विकास पर फिर से ध्यान केंद्रित किया। MS-DOS पक्ष पर MSC 6 के माध्यम से मिश्रित भाषा संगतता बनी रही, लेकिन Microsoft Windows 3.0 और 3.1 के लिए API को MSC 6 में लिखा गया था। MSC 6 को 32-बिट असेंबली के लिए समर्थन प्रदान करने और कार्यसमूहों के लिए उभरते विंडोज़ के लिए समर्थन प्रदान करने के लिए भी विस्तारित किया गया था। और Windows NT जो Windows XP के लिए नींव तैयार करेगा। थंक नामक एक प्रोग्रामिंग अभ्यास को 16- और 32-बिट प्रोग्राम के बीच पारित करने की अनुमति देने के लिए पेश किया गया था, जो अखंड प्रणाली 16-बिट एमएस-डॉस अनुप्रयोगों में पसंदीदा स्थिर बंधन के अतिरिक्त रनटाइम बाइंडिंग (गतिशील लिंकिंग) का लाभ उठाता था। स्थैतिक बंधन अभी भी कुछ देशी कोड डेवलपर्स द्वारा समर्थित है, लेकिन सामान्यतः क्षमता परिपक्वता मॉडल (सीएमएम) जैसी नई सर्वोत्तम प्रथाओं के लिए आवश्यक कोड पुन: उपयोग की डिग्री प्रदान नहीं करता है।

MS-DOS समर्थन अभी भी Microsoft के पहले C++ कंपाइलर, MSC 7 की रिलीज़ के साथ प्रदान किया गया था, जो C प्रोग्रामिंग भाषा और MS-DOS के साथ पिछड़ा संगत था और 16- और 32-बिट कोड जनरेशन दोनों का समर्थन करता था।

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

MS-DOS और 16-बिट कोड जनरेशन समर्थन MSC 8.00c तक जारी रहा, जिसे Microsoft C++ और Microsoft अनुप्रयोग स्टूडियो 1.5 के साथ बंडल किया गया था, जो Microsoft Visual Studio का अग्रदूत है जो आज Microsoft द्वारा प्रदान किया जाने वाला क्रॉस डेवलपमेंट वातावरण है।

1990 के दशक के अंत में

MSC 12 को Microsoft Visual Studio 6 के साथ जारी किया गया था और अब MS-DOS 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 के लिए निष्पादन योग्य बनाने में सक्षम है (देखें ). चूंकि , किसी अन्य आर्किटेक्चर के कंपाइलिंग के लिए, कंपाइलर का एक क्रॉस आर्किटेक्चर संस्करण पहले बनाया जाना चाहिए। परिणामी संकलक निष्पादन योग्य के नाम में लक्ष्य आर्किटेक्चर से पहले अतिरिक्त 'रॉस' होगा। अर्थात यदि कंपाइलर x64 को लक्षित करने के लिए बनाया गया है, तो निष्पादन योग्य ppcrossx64 होगा।

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

क्लैंग

क्लैंग मूल रूप से एक क्रॉस कंपाइलर है, निर्माण समय पर आप चुन सकते हैं कि आप किस आर्किटेक्चर को क्लैंग को लक्षित करने में सक्षम होना चाहते हैं।

यह भी देखें

• मिनजीडब्ल्यू
• स्क्रैचबॉक्स
• नि: शुल्क पास्कल
• क्रॉस असेम्बलर

बाहरी संबंध

• 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 लिनक्स from 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 from Windows to लिनक्स , a subject rarely developed