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

From Vigyanwiki
Revision as of 15:30, 17 February 2023 by alpha>Indicwiki (Created page with "{{Short description|Cross-platform machine-code compiler}} {{Program execution}} एक क्रॉस कंपाइलर एक कंपाइलर है जो एक...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
कार्यक्रम निष्पादन
सामान्य अवधारणाएँ
कोड के प्रकार
संकलन रणनीतियाँ
उल्लेखनीय रनटाइम्स
उल्लेखनीय संकलक और टूलचेन

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

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

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

प्रयोग

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

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

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

आमतौर पर हार्डवेयर वास्तुकला भिन्न होता है (उदाहरण के लिए x86 कंप्यूटर पर MIPS आर्किटेक्चर के लिए नियत प्रोग्राम को कोड करना) लेकिन क्रॉस-संकलन भी तब उपयोगी होता है जब केवल ऑपरेटिंग सिस्टम का वातावरण अलग होता है, जैसे कि Linux के तहत एक FreeBSD प्रोग्राम को संकलित करते समय, या यहां तक ​​​​कि सिस्टम लाइब्रेरी , जैसे किसी glibc होस्ट पर uClibc के साथ प्रोग्राम संकलित करते समय।

कैनेडियन क्रॉस

कैनेडियन क्रॉस अन्य मशीनों के लिए क्रॉस कंपाइलर्स बनाने की एक तकनीक है, जहां मूल मशीन लक्ष्य से बहुत धीमी या कम सुविधाजनक है। तीन मशीनों A, B, और C को देखते हुए, एक मशीन B पर चलने वाले क्रॉस कंपाइलर (जैसे x86-64 प्रोसेसर पर Mac OS X चलाना) बनाने के लिए मशीन A (जैसे IA-32 प्रोसेसर पर Windows XP चलाना) का उपयोग करता है। मशीन सी के लिए निष्पादन योग्य बनाएं (उदाहरण के लिए एआरएम वास्तुकला प्रोसेसर पर एंड्रॉइड (ऑपरेटिंग सिस्टम) चलाना)। इस उदाहरण में व्यावहारिक लाभ यह है कि मशीन A धीमी है, लेकिन उसके पास मालिकाना संकलक है, जबकि मशीन B तेज़ है, लेकिन उसका कोई संकलक नहीं है, और मशीन C संकलन के लिए उपयोग किए जाने के लिए अव्यावहारिक रूप से धीमी है।

जीसीसी के साथ कैनेडियन क्रॉस का उपयोग करते समय, और जैसा कि इस उदाहरण में है, इसमें चार कंपाइलर शामिल हो सकते हैं

  • मशीन ए (1) के लिए 'मालिकाना नेटिव कंपाइलर' (उदाहरण के लिए माइक्रोसॉफ्ट विजुअल स्टूडियो से कंपाइलर) का उपयोग मशीन ए (2) के लिए जीसीसी नेटिव कंपाइलर बनाने के लिए किया जाता है।
  • मशीन A (2) के लिए gcc नेटिव कंपाइलर का उपयोग मशीन A से मशीन B (3) तक gcc क्रॉस कंपाइलर बनाने के लिए किया जाता है
  • जीसीसी क्रॉस कंपाइलर मशीन ए से मशीन बी (3) का इस्तेमाल जीसीसी क्रॉस कंपाइलर मशीन बी से मशीन सी (4) बनाने के लिए किया जाता है

कैनेडियन क्रॉस, योजना का उदाहरणअंतिम-परिणाम क्रॉस कंपाइलर (4) बिल्ड मशीन A पर नहीं चल पाएगा; इसके बजाय यह एक एप्लिकेशन को निष्पादन योग्य कोड में संकलित करने के लिए मशीन बी पर चलेगा जिसे मशीन सी में कॉपी किया जाएगा और मशीन सी पर निष्पादित किया जाएगा।

उदाहरण के लिए, NetBSD एक POSIX Unix शेल स्क्रिप्ट प्रदान करता है जिसका नाम है build.sh जो पहले होस्ट के कंपाइलर के साथ अपना toolchain बनाएगा; बदले में, इसका उपयोग क्रॉस कंपाइलर बनाने के लिए किया जाएगा जिसका उपयोग पूरे सिस्टम को बनाने के लिए किया जाएगा।

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


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

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

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

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

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

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

क्रॉस-कंपाइलिंग जीसीसी के लिए आवश्यक है कि लक्ष्य प्लेटफॉर्म की सी मानक लाइब्रेरी का एक हिस्सा होस्ट प्लेटफॉर्म पर उपलब्ध हो। प्रोग्रामर पूर्ण सी पुस्तकालय को संकलित करना चुन सकता है, लेकिन यह विकल्प अविश्वसनीय हो सकता है। विकल्प newlib का उपयोग करना है, जो एक छोटी सी लाइब्रेरी है जिसमें सी (प्रोग्रामिंग भाषा) स्रोत कोड को संकलित करने के लिए आवश्यक सबसे आवश्यक घटक हैं। जीएनयू बिल्ड सिस्टम पैकेज (अर्थात autoconf़, automake और libtool) एक बिल्ड प्लेटफ़ॉर्म, एक होस्ट प्लेटफ़ॉर्म और एक लक्ष्य प्लेटफ़ॉर्म की धारणा का उपयोग करते हैं। बिल्ड प्लेटफॉर्म वह जगह है जहां कंपाइलर वास्तव में संकलित होता है। ज्यादातर मामलों में, बिल्ड को अपरिभाषित छोड़ दिया जाना चाहिए (यह होस्ट से डिफ़ॉल्ट होगा)। होस्ट प्लेटफ़ॉर्म हमेशा वह होता है जहाँ कंपाइलर से आउटपुट कलाकृतियों को निष्पादित किया जाएगा चाहे आउटपुट कोई अन्य कंपाइलर हो या नहीं। लक्ष्य प्लेटफ़ॉर्म का उपयोग तब किया जाता है जब क्रॉस-कंपाइलर क्रॉस-कंपाइलर होते हैं, यह दर्शाता है कि पैकेज किस प्रकार का ऑब्जेक्ट कोड उत्पन्न करेगा; अन्यथा लक्ष्य प्लेटफ़ॉर्म सेटिंग अप्रासंगिक है।[2] उदाहरण के लिए, एक कलाकारों का सपना पर चलने वाले वीडियो गेम को क्रॉस-कंपाइल करने पर विचार करें। मशीन जहां गेम को संकलित किया गया है वह बिल्ड प्लेटफॉर्म है जबकि ड्रीमकास्ट होस्ट प्लेटफॉर्म है। नाम मेजबान और लक्ष्य संकलक के सापेक्ष उपयोग किए जा रहे हैं और बेटे और पोते की तरह स्थानांतरित किए जा रहे हैं।[3] एम्बेडेड लिनक्स डेवलपर्स द्वारा लोकप्रिय रूप से उपयोग की जाने वाली एक अन्य विधि में scratchbox2, स्क्रैचबॉक्स 2, या PRoot जैसे विशेष सैंडबॉक्स के साथ जीसीसी कंपाइलर्स का संयोजन शामिल है। ये उपकरण एक चिरोटेड सैंडबॉक्स बनाते हैं जहां प्रोग्रामर अतिरिक्त पथ सेट किए बिना आवश्यक उपकरण, libc और लाइब्रेरी बना सकता है। रनटाइम को धोखा देने के लिए सुविधाएं भी प्रदान की जाती हैं ताकि यह विश्वास हो सके कि यह वास्तव में लक्षित लक्ष्य सीपीयू (जैसे एआरएम आर्किटेक्चर) पर चल रहा है; यह कॉन्फ़िगरेशन स्क्रिप्ट और बिना किसी त्रुटि के चलने की अनुमति देता है। स्क्रैचबॉक्स गैर-क्रोट किए गए तरीकों की तुलना में अधिक धीमी गति से चलता है, और अधिकांश उपकरण जो होस्ट पर हैं उन्हें कार्य करने के लिए स्क्रैचबॉक्स में ले जाना चाहिए।

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

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

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

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

मैनक्स का एज़्टेक 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 के लिए समर्थन जोड़ा[8] और जो बेसलाइन MS-DOS संस्करण 3 की तुलना में कम मजबूत थे और बाद में जिन्हें एज़्टेक C86 ने अपने अंत तक लक्षित किया।

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

थॉमस फेनविक और जेम्स गुडनाउ 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 ने MS-DOS के लिए एक क्रॉस लैंग्वेज डेवलपमेंट एनवायरनमेंट की पेशकश की। असेंबली लैंग्वेज (MASM) और Microsoft की अन्य भाषाओं में QuickBASIC, पास्कल (प्रोग्रामिंग भाषा), और फोरट्रान सहित लिखे गए 16-बिट बाइनरी ऑब्जेक्ट कोड को एक साथ एक प्रोग्राम में जोड़ा जा सकता है, एक प्रक्रिया में वे मिश्रित भाषा प्रोग्रामिंग और अब इंटरलैंग्वेज कॉलिंग कहलाते हैं।[12] यदि इस मिश्रण में 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 प्रोग्राम के लिए Linux जैसे अन्य ऑपरेटिंग सिस्टम के लिए अनुकूलता प्रदान करते हैं।

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

फ़्री पास्कल

Free Pascal को शुरुआत से ही एक cross Compiler के रूप में विकसित किया गया था। कंपाइलर एक्जीक्यूटेबल (ppcXXX जहां XXX एक लक्षित आर्किटेक्चर है) एक ही आर्किटेक्चर के सभी ओएस के लिए एक्जीक्यूटिव (या अगर कोई आंतरिक लिंकर मौजूद नहीं है, या यहां तक ​​​​कि अगर कोई आंतरिक असेंबलर मौजूद नहीं है तो सिर्फ असेंबली फाइल) बनाने में सक्षम है। उदाहरण के लिए, ppc386 i386-linux, i386-win32, i386-go32v2 (DOS) और अन्य सभी OSes के लिए निष्पादन योग्य बनाने में सक्षम है (देखें [13]). हालाँकि, किसी अन्य आर्किटेक्चर के संकलन के लिए, कंपाइलर का एक क्रॉस आर्किटेक्चर संस्करण पहले बनाया जाना चाहिए। परिणामी संकलक निष्पादन योग्य के नाम में लक्ष्य वास्तुकला से पहले अतिरिक्त 'रॉस' होगा। यानी यदि कंपाइलर x64 को लक्षित करने के लिए बनाया गया है, तो निष्पादन योग्य ppcrossx64 होगा।

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

क्लैंग

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

यह भी देखें

संदर्भ

  1. ↑ "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.
  2. ↑ "Cross-Compilation (Automake)".
  3. ↑ "Cross compilation".
  4. ↑ "Obsolete Macintosh Computers". Archived from the original on 2008-02-26. Retrieved 2008-03-10.
  5. ↑ Aztec C
  6. ↑ Commodore 64
  7. ↑ Apple II
  8. ↑ MS-DOS Timeline Archived 2008-05-01 at the Wayback Machine
  9. ↑ Inside Windows CE (search for Fenwick)
  10. ↑ Microsoft Language Utility Version History
  11. ↑ History of PC based C-compilers Archived December 15, 2007, at the Wayback Machine
  12. ↑ Which Basic Versions Can CALL C, FORTRAN, Pascal, MASM
  13. ↑ "Free Pascal Supported Platform List". Platform List. Retrieved 2010-06-17. i386


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=क्रॉस_कंपाइलर&oldid=100055’